Skip to content
Topic

Agents and Automation

Building things that run without you — chains, agents and workflow automation, and the discipline about authority that decides whether they are safe to leave running.

There is a real difference between an assistant that drafts and an agent that acts, and it is not a matter of degree. A bad draft is one you delete; a bad action has already sent the email or cancelled the booking. That asymmetry should govern how any of this is built, and it is the thing most enthusiasm about agents skips. This hub covers the progression that works — automate a process you already do reliably, split work into steps that can each be checked, and grant autonomy narrowly and slowly — along with the monitoring that makes a running system something you can trust rather than something you quietly turn off.

Chains before agents

A single prompt asked to research, analyse, write and format will do all four adequately and none well. Splitting the work into steps, each with one job and a check between them, produces better results and makes failures visible where they happen rather than three steps later. Most of what people want from agents is actually a chain: deterministic control flow with a model doing the judgement at specific points. Chains are easier to build, far easier to debug, and sufficient more often than the agent framing suggests.

Structured output is what makes it hold together

Whenever a model's answer feeds another step, ask for structured data with named fields rather than prose you then parse. Parsing prose is where these pipelines break. Validate between stages, add a filter after every model step so an unexpected answer stops the run rather than propagating, and always build the error path at the same time as the happy path — added afterwards, it only gets added to the steps you remembered.

Grant authority slowly

Start in propose-and-approve mode on one narrow, reversible task, and treat that mode as where you learn what the system actually does with real inputs rather than as a stage to rush through. Enforce the things that must never happen in code rather than in a prompt: a system prompt is a strong default that a persuasive input can argue with. Keep anything involving money, external communication or an irreversible change behind a person for far longer than feels necessary.

If you cannot see it, it is not running well

An agent in production needs to be observable to the standard that you could reconstruct what it did and why. Log inputs, decisions, tool calls and results, and make failures louder than successes — a system that fails silently is worse than one that never ran, because the work is not happening and nothing says so. Review successful runs too, not just errors: the failure that hurts is a plausible wrong answer that never raised an exception.

Build the chain before the agent, ask for structured output, validate between steps, and widen authority only where the log shows it has been earned. The engineering here is not the hard part — the discipline about what a system may do without asking is what separates automation you can leave running from automation you end up switching off.

Try it yourself

The free plan includes 100 credits and needs no card.