Handing a real process to an agent

Every few months a company hands something serious to an agent and the result travels. TechCrunch reported on 9 July 2026 that Lyzr, a startup that helps enterprises build AI agents, had let an agent called SivaClaw run point on its own $100 million Series B, raised at a valuation of roughly $500 million; the agent fielded questions from more than 130 investors, drafted investment memos, and tracked which slides backers lingered on [8]. The useful reaction to that is not admiration. It is the flat question of whether anything you do has the same shape, because the reason it worked has very little to do with how clever the model was.

This guide is for a solo operator or a small team with one repetitive, documented process that eats a day a week, wondering whether to hand it over. It is not for anyone shipping an agent as a product to customers, where the failure surface is somebody else’s business, and it is not for a process where a regulator, an insurer or a client contract already dictates who signs off. If that is your situation, the sign-off requirement decides the design and nothing below changes it.

Four properties decide whether a process can be handed over

The first property is bounded variance. You want many instances of a task that differ from each other in ways you could describe in a paragraph. A hundred supplier questions about your delivery terms have real variance and a small amount of it. A hundred inbound sales calls do not.

The second is that the answers already exist in writing. Agents suit workflows that lean heavily on unstructured data and on rules that have grown too fiddly to maintain by hand, and they suit decisions that need context rather than a lookup table [3]. What they cannot do is invent your policy. If the answer to a common question lives only in your head, the agent will produce something plausible in its place, and you will find out later.

The third is that the work is asynchronous. A question that can wait 20 minutes for an answer removes almost every hard engineering problem from the design. Live conversation puts them all back.

The fourth is that the outcome is checkable afterwards by someone who was not watching. If you cannot look at a completed instance and say whether it went well, you cannot supervise the agent at any volume, and you are not delegating so much as hoping.

Make puts the same test more bluntly than most vendors do: “If it just needs doing, use automation. If it needs thinking, use Make AI Agents.” [7] That is the right order of preference, and most people try it in reverse.

Most of what you want to hand over is a workflow, not an agent

There is a cheaper answer than an agent and it is worth ruling out first. Anthropic draws the line this way: workflows offer predictability and consistency for well-defined tasks, while agents are the better option when flexibility and model-driven decision-making are needed at scale [2]. Agents earn their keep on open-ended problems where you cannot predict the number of steps in advance and cannot hardcode the path [2].

The cost of getting that wrong is not only money. “The autonomous nature of agents means higher costs, and the potential for compounding errors,” is Anthropic’s own summary [2]. A fixed automation that breaks tends to break loudly and in the same place every time. An agent that goes wrong in step 2 of 9 produces seven more steps of confident work on a bad premise, and the output still looks like the good ones.

If you do need an agent, start with one. OpenAI’s guidance is to maximise a single agent’s capabilities first, because adding agents introduces complexity and overhead before it adds much else [3]. The instinct to build a team of specialists is usually the instinct to avoid writing down what the single agent should do.

Permissions are the design, not a settings screen

This is the part people skip, and it is the part that determines whether handing over the process was reasonable.

Look at how the Claude Agent SDK actually decides whether a tool call runs. Every request passes through six steps in order: hooks, deny rules, ask rules, the permission mode, allow rules, and finally a canUseTool callback that asks a human [1]. The order carries the whole lesson. A deny rule blocks a tool even in bypassPermissions mode, and an ask rule still routes the call to a human in that mode [1]. A hook runs before every other step, so a check written as a hook applies to every call there is [1].

The failure most people build for themselves is in the other direction. Auto-approved tools never reach your approval callback, so a permission check you put there is silently bypassed for anything an allow rule already cleared [1]. Naming a tool bare, as Read, approves every call to it; scoping it, as Bash(ls *), approves only the matching ones and leaves the rest to be asked about [1]. And allowed_tools does not constrain bypassPermissions at all: listing Read alongside that mode still approves Bash, Write and Edit [1]. Anthropic’s own wording on that mode is “Use with extreme caution. Claude has full system access in this mode.” [1] For a process running unattended, the documented shape is the opposite: pair an explicit allowedTools list with dontAsk mode, so anything unlisted is denied outright rather than quietly waiting for a prompt nobody will answer [1]. One more trap, if you split work between agents: subagents inherit the parent session’s permission mode, and a parent in bypassPermissions hands that to all of them, overriding whatever the subagent definition asked for [1].

The hosted tools express the same idea with fewer dials. ChatGPT agent “will pause for clarification or confirmation when needed”, hands you the browser in takeover mode where screenshots stop being captured so passwords stay yours, and runs a watch mode that requires supervision on certain sites [4]. Those are defaults someone chose for you. In your own build, you choose them.

Write the deny list before the task list. The question to answer is not what the agent should be able to do; it is which single action, taken wrongly at 3am, you could not undo by Monday. Send money. Email a client list. Delete a record. Publish. Put those behind a deny rule or an approval step first, then give the agent everything else and stop worrying about the rest.

Write the escalation rule before the happy path

An agent running a real process spends most of its time on cases it can handle and earns its reputation on the ones it cannot. Decide in advance what it does with those, because the default behaviour of a language model faced with a gap is to fill it.

There are two escalation triggers worth writing down on day one. OpenAI names both: exceeding failure thresholds, meaning the agent has tried and failed repeatedly, and high-risk actions, the class that includes order cancellations and large refunds [3]. Repeated failure is the easier one to instrument and the one people forget, because it requires the agent to count its own attempts rather than try once more.

Around that sits a layered defence rather than a single check. The published pattern combines rules-based filters, moderation, relevance and safety classifiers, personal-data filters, and tool safeguards that assign a risk rating to each tool [3]. You do not need all of those for a five-person operation. You need the risk rating, even if it is a list of three tools you wrote on paper, and you need the agent to be able to stop: Anthropic’s design guidance is that agents pause for human feedback at checkpoints or when they hit a blocker [2].

The rule that matters is short. When the answer is not in the documented material, the agent escalates rather than improvises, and the escalation goes somewhere with a name attached and a response time you have agreed to. An escalation into a shared inbox is not an escalation.

If it talks to anyone outside your company, say that it is an agent

This stopped being an etiquette question in Europe on 2 August 2026, when the AI Act became applicable and the Commission began enforcing the new transparency requirements [6]. Article 50 requires that AI systems intended to interact directly with natural persons are designed so that those people are informed they are interacting with an AI system, unless that is obvious to a natural person who is reasonably well-informed, observant and circumspect, taking the circumstances and the context of use into account [5]. The information has to be given “in a clear and distinguishable manner at the latest at the time of the first interaction or exposure” [5].

Two practical readings follow. First, the obligation in paragraph 1 sits with providers, but paragraph 5, which sets the timing and clarity, covers the disclosures owed by providers and deployers alike [5]. If you are a small operator running someone else’s agent against your own customers, you are the deployer, and the timing requirement is yours to meet. Second, there is a related rule for generated text: where AI-generated text is published to inform the public on matters of public interest, disclosure is required unless a natural or legal person holds editorial responsibility for the publication [5].

None of that is onerous. One sentence at the top of the first message, in the same size type as everything else, discharges most of it. The reason to do it even outside the EU is that the alternative fails badly. A counterparty who works out mid-process that they have been talking to software, after you let them assume otherwise, does not get annoyed about the software.

Measure your own error rate before you widen the gate

The Lyzr round demonstrates that a high-stakes, multi-party process can run this way. It gives you no failure budget. The published account records what the agent did across more than 130 investors and the $400 million in interest the company says that produced [8]; it does not record how often the agent was wrong, what a founder had to step in and fix, or which questions it should have refused. You cannot calibrate your own tolerance from someone else’s success story, and that is true of every case study you will read this year.

So generate the number yourself, on your own process, before the agent is load-bearing. Anthropic’s recommendation is extensive testing in sandboxed environments alongside the appropriate guardrails [2]. In a small operation that means a shadow run: the agent handles the same cases you are already handling, writes its answer where only you can see it, and you compare. Two weeks of that gives you three numbers worth more than any benchmark. The share it got right. The share it escalated. And the share it got wrong while sounding certain, which is the only one that can hurt you, and the only one you will never learn from a dashboard.

What still goes wrong

The escalation path rots first. It works in week 1 because you built it, and by week 8 the notifications go to a channel that has been muted, or to a person who stopped reading them once most of what arrived turned out to be routine. An escalation route needs an owner and a review date the same way a payment method does, and the failure is silent by construction: nothing breaks, the queue just grows.

Permission configuration drifts as well. You add a connector for one useful task, the allow list grows a bare tool name, and the careful gate you wrote three months ago is now bypassed for that whole tool without anything appearing to change [1]. Re-read the deny list whenever you give the agent a new capability, and treat any move to a bypass mode as a decision with a date on it rather than a convenience.

The deeper limit is that a well-run agent optimises the thing you measured. If the measure is cases closed, you will get cases closed, including the ones a person would have recognised as the start of a real conversation with a customer worth having. The Lyzr account is measured in investors fielded and in dollars of stated interest [8], because those are the numbers that were easy to count; what a process is for is rarely one of them. Handing over a process is not the same as handing over the judgment about what the process is for, and no permission setting will keep that line for you.