A general assistant knows everything except your business.

Both. For a workflow specific to your business, we build a custom agent around it: your systems, your rules and your authority limits. For common jobs such as phone booking, selling through chat, or scheduling, we can start from an agent we have already built, such as our voice booking agent, Stella or Zennly, and adapt it to your rules instead of building from scratch. Tell us about the work and we will say which route fits, or that an agent is the wrong tool.

A general assistant answers questions; an agent completes work. The difference that matters in practice is authority and integration — a custom agent holds credentials for your systems, takes actions in them under rules you set, runs on a schedule rather than when someone remembers, and logs what it did. Uploading documents to a chat window gives you none of that.

Explicit bounds rather than good intentions. Each agent gets a fixed set of tools, limits on what those tools may do, and approval gates on the steps you nominate. Anything outside that set is not refused by the model — it is simply not available to it, which is a stronger guarantee.

One that is repetitive, has a clear definition of done, and where somebody can tell quickly whether the output is right. Those three properties matter more than how impressive the workflow sounds, because they are what let us measure the agent against reality rather than against a demo.

It should be visible and recoverable, which is a design requirement rather than an afterthought. Actions are logged and reversible where the underlying system allows it, low-confidence cases route to a person before acting, and we track the escalation rate as a headline metric — an agent whose escalation rate is falling while accuracy holds is working.

Usually less than people assume. Agents cope with messy source documents better than traditional automation, because reading unstructured input is the thing they are good at. What does need to be in order is the destination — the system being written to — and the rules the work is checked against.

You own the code, the prompts, the configuration and the data. It deploys into your infrastructure, and the handover includes documentation and credentials. Models are called through providers, so switching provider later is a configuration change rather than a rebuild.