7 posts tagged with "Cloudflare"

To close port 22 without a VPN: put SSH behind an outbound-only tunnel with an identity check at the edge, prove the new path works, then delete the old port-22 firewall rule over that new path. Nothing on the host listens for inbound connections, and no mesh VPN client has to share the laptop with a corporate one.

An exposed SSH port is not the likeliest way your AI agent's VPS gets owned. It is the likeliest way you lose the ability to fix the machine.

The standard recipe keeps port 22 shut to the world, opens it to your own address, and adds a mesh VPN when you need to get in from anywhere. Both halves tie the security of a machine that holds live API keys to something you do not control: your ISP's address pool, and a laptop routing table that a corporate VPN client already owns. What I would reach for instead is Cloudflare Tunnel with Cloudflare Access in front — an outbound-only connection plus an identity check, which takes both dependencies out of the security model.

The Cloudflare Tunnel overview states its promise in a single line: connect your origin servers, APIs, and services to Cloudflare "with post-quantum encrypted tunnels — no public IPs required."

That sentence describes the software's default behaviour. One level down, in the run-parameter reference, the same documentation explains what happens when the default does not hold. cloudflared connects over QUIC using post-quantum cryptography, the docs say, "but will fall back to non-PQ if there are issues connecting."

Both statements are accurate. The distance between them is one flag wide, and Cloudflare's own roadmap explains why that distance matters: "Adding support for PQ cryptography is not enough. Systems must disable support for quantum-vulnerable cryptography to be secure against downgrade attacks." The tunnel ships the support. The flag is how you disable the fallback.

The most effective sales-enablement copilot in our production fleet never sends a single message. That cuts against every vendor demo where a glowing AI drafts the perfect rebuttal and fires it off. This sales-enablement copilot does grounded deal coaching and objection handling, but in production the highest-leverage capability is not generation — it is holding fire. The agentic-sales fleet runs a LangGraph state machine where every objection-handling draft is stamped status='draft' and routed to a human for approval. The copilot coaches, suggests, and grounds its advice in company knowledge, but it never touches the send button. That single design choice turns a liability into an asset: the rep gets a grounded, auditable recommendation that she still owns.

On the fleet's autonomy ladder this capability sits deliberately medium — it is rep-assist, not self-direction. It automates the plan step: what grounded coaching and rebuttal a given objection deserves. But it hands both act and verify to the human. The copilot drafts and grounds; the rep decides and sends. That is a conscious rung below the orchestrator and the lead-to-proposal multi-agent pipeline. The failure cost of an objection rebuttal — repeating a hallucinated compliance claim to a live prospect — is high enough that earning the send is not worth it.

This is article #4 in The Autonomous Sales Fleet series, and like every entry it adds exactly 1 capability as 1 real graph: a company-knowledge-grounded objection-handling copilot that feeds the reply path, backed by a faithfulness gate and a per-vertical playbook of 9 entries. It builds on the shared fleet introduced in An Autonomous CRM Orchestrator with LangGraph (#1) and the typed task sequencing of A Multi-Step Lead-Qualification and Sales-Support Agent (#2).

From Scripted Chatbot to Multi-Step Sales Agent: How to Build a Lead Qualification Sequence That Works​

A multi-step lead qualification agent earns its autonomy by sequencing work no human queued: it decomposes an inbound signal into an ordered plan, grades each step against real data, and stops at a human-approval interrupt before anything ships. That is the line between a scripted chatbot and an agent — not a newer model or a sharper prompt, but a decision about who gets to sequence work. A chatbot automates a single turn; an agent automates the workflow that turn belongs to. On the fleet's autonomy ladder this capability sits high: it takes over the human plan step for an inbound lead — deciding which qualification and analysis tasks to run, and in what order — while every act stays a draft held for human verify.

The autonomy guard here is conservative by construction. The agent never sends; it composes, and the message is held as a pending draft behind a confirm-before-mutate interrupt, with a deterministic safety veto sitting upstream of the planner so a hostile or malformed plan can never reach a suppressed contact. That is the posture this article builds: reasoning is delegated, action is gated. Article #1's orchestrator dispatches into this qualifier; this is where the fleet first replaces a rep's "is this lead worth my time, and what do I do next?" judgement with a graded, auditable, draft-first sequence.

This is article #2 in The Autonomous Sales Fleet, a connected series describing one production agentic-sales system where each piece adds exactly one capability. The fleet shares a single architecture: a control plane of LangGraph StateGraphs, a data plane on Cloudflare (D1, Workers, Queues), and an observability plane of LangSmith tracing with per-graph golden datasets. Every LLM call exits through one DeepSeek endpoint behind a Cloudflare AI Gateway; no graph ships unless its golden dataset passes an eval gate; every persisted AI decision carries a four-field provenance record; and outreach is always draft-first, held for human approval. This article builds on The Autonomous CRM Orchestrator on LangGraph (#1) and connects forward to the Lead-to-Proposal Multi-Agent Pipeline (#3), which takes the qualified lead as a conceptual starting point.

The strongest evidence for constraining an agent the way this one does comes from AgentArch (Bogavelli, Sharma & Subramani, 2025), a benchmark of 18 agentic configurations across orchestration, prompt strategy, memory, and thinking-tool usage. It finds "significant model-specific architectural preferences" that break the one-size-fits-all assumption, with top models clearing only 35.3% of the complex enterprise task and 70.8% of the simpler one. When even the best configuration fails two of three hard tasks, an open-ended agent loop is a liability — and a closed, typed, narrow planner is the defensible bet. That is precisely the change this article walks through in a real email_orchestrator graph. Industry framing pieces such as Rai (2026) draw the same chatbot-versus-agent line conceptually; the engineering case rests on the indexed and canonical work cited below.

We needed a pipeline that ingests hundreds of job postings from ATS platforms (Greenhouse, Lever, Ashby), enriches each posting with structured data from their public APIs, and then classifies whether a job is a fully remote EU position — all running on Cloudflare's edge with zero GPU costs.

This article walks through the architecture and implementation of process-jobs, a Cloudflare Python Worker that combines langchain-cloudflare with Cloudflare Workers AI, D1, and Queues to build a production classification pipeline.

This article documents a production implementation of OpenAI's Text-to-Speech (TTS) API with automatic chunking for long-form content and seamless upload to Cloudflare R2 storage.