Deploying an agent on a real workflow

You now have the pieces: a model, a loop, tools, grounding, and guardrails. Deployment is wiring them to a real channel and a real system, then hardening it. Here is the shape of a working agent in production.

The architecture

Sessions and state

Each customer needs a session: a thread that holds their recent messages so the agent has continuity, keyed by their phone number or a chat id. Decide how much history to keep in context (recent turns plus a short summary of older ones is a good default) and where to store the rest. This is the practical side of the memory lesson.

Webhooks: how messages get in

A channel like WhatsApp (via a provider) calls a URL on your server every time a customer sends a message. That webhook is the entry point: it receives the message, loads the session, runs the agent loop, sends the reply back through the provider, and records what happened. Everything the agent does starts from one inbound webhook.

Prototype to production

• Log every step: the prompt, the tool calls, the result. When something goes wrong you will need the trace.
• Start with a human in the loop: the agent drafts, a person approves, until the eval scores earn your trust.
• Ship to a narrow slice first: one channel, one use case, real but limited volume.
• Watch the metrics: resolution rate, handoff rate, cost per conversation, and the failures.
• Have an off switch and a rollback. You will change the prompt; be able to undo it.

Build the smallest version that touches one real workflow, keep a human approving at first, measure it, and widen only once the numbers hold. That discipline, not a clever prompt, is what separates an agent that survives contact with real customers from a demo that does not.