I wanted to run our operations the way I run a team. I hand a goal to someone who owns it, they come back with a report, and I never read the steps. With LLM agents that idea is tempting, because an agent with a role and its own tools looks a lot like a staff member. So before we turned more of our scripts into agents, I read what the papers, the vendor guides and the framework authors say about when that works.
The short answer is that delegation to agents is right at the edge and wrong in the middle. Each domain gets one agent that owns the outcome and reports back to me. The work inside that domain stays as deterministic functions the agent calls. The evidence punishes agents split along an org chart, several writers on one artifact, and a model running where a script would give the same answer. We had all of those in our own estate.
The actor model treats each agent as a colleague with its own role and memory: you delegate, it decides, it reports back. The function model keeps the work as deterministic workflows that do the same thing on every run, with a model called only where a step needs judgment.
Each model makes a bet. The actor model bets that the agent remembers what happened last month, gets each step right often enough to be left alone, and coordinates cleanly with the other actors. The function model bets that someone can write the steps down, that the inputs fit a schema, and that a change in the work is a code edit.
The actor picture holds up well at the edge of a domain:
- Ownership. One named agent answers for an outcome, which is how a manager already thinks about work.
- Judgment. Messy input, unclear rules and open-ended search are where a model beats a rule set 6.
- Reporting. A plain-language summary of what happened is the most natural interface a person can get.
It breaks in the middle, where the work happens:
- Memory. Agent memory systems lose about 30% on long interactions 20, and every tested model degrades as its context grows 18.
- Reliability. Small per-step error rates compound over long chains, which Section “When a workflow wins” works through.
- Multiple writers. Agents that each write to the same artifact are the most repeated failure in the multi-agent literature 7 16.
So I keep the actor at the edge and functions in the middle: the owner agent is the actor, and everything it calls is a function.
A workflow runs a path someone wrote down in advance. An agent picks its own path, one tool call at a time, in a loop, and decides when it is done.
That is the line Anthropic draws in its guide to building agents 1, and Simon Willison's working definition says the same thing in fewer words: an agent is a model running "tools in a loop to achieve a goal" 3. Harrison Chase at LangChain points out that real systems sit on a spectrum between the two ends 2. Naming the rungs makes "should this be an agent" answerable.
- L0, function. A cron script or plain function. Same input, same output.
- L1, workflow with one typed LLM step. Code runs the path, and one step asks a model for structured output that code then validates and writes.
- L2, owner agent. One agent with tools and a bounded loop, owning one domain.
- L3, owner plus read-only helpers. The owner spawns helpers that search or review in a clean context and return a summary. Only the owner writes.
- L4, peer agents. Several agents that each write and negotiate with each other. Nothing we run should sit here.
The owner agent buys flexibility and a natural interface for a manager. The function buys repeatability, a near-zero cost per run, and failures that announce themselves.
| Property | Owner agent | Function or workflow |
|---|---|---|
| Handles new situations | Yes | No, fails loudly |
| Same input, same output | No | Yes |
| Cost per run | High, grows with context | Near zero |
| Debugging | Read traces | Read code and logs |
| Interface for a manager | Delegate, get a report | Read a dashboard |
| Failure mode | Silent and confident | Loud and specific |
| Memory | Weak inside; strong in files | State in a store by design |
| Audit | Only what you log | Event history, replayable |
The audit row is the one teams notice last. A durable workflow engine records every step and can replay a run from its history 40. An agent leaves a trace only if you built the logging around it.
An agent earns its cost when the next step depends on what the last step found, when the work spreads wide and only reads, or when the input is messy enough that rules would be unwieldy. Outside those cases you are paying for flexibility you don't use.
The open path is the defining case. If I can't tell you the steps before the run starts, a fixed workflow has nothing to encode 1. OpenAI's practical guide reserves agents for complex decisions, unwieldy rule sets and unstructured data, and says plainly that otherwise "a deterministic solution may suffice" 6.
Breadth-first research is where the biggest number comes from. Anthropic's lead agent with parallel subagents beat a single agent by 90.2% on its internal research eval 4. Read the cost line in the same post before copying the design: the multi-agent system used about 15 times the tokens of a chat, and token use alone explained 80% of the variance in performance 4.
Decomposable work also gains. Kim and colleagues at Google and MIT measured multi-agent setups gaining up to 80.8% on finance tasks that split into independent parts 5.
A clean-context reviewer is the cheapest win I found. Cognition reports that a reviewer agent with fresh context finds about two bugs per pull request from their coding agent, and about 58% of those are severe 7. The reviewer reads and reports. It never writes the code it reviews.
A workflow wins when you can write the steps down today or when the chain is long, and it should always own money and irreversible state. Fixed flows cost less and fail loudly where an agent fails quietly.
The accuracy result surprised me most. Agentless solved 32% of SWE-bench Lite at an average of $0.70 per issue with no agent loop at all 8. AlphaCodium's fixed flow nearly doubled GPT-4's accuracy on competitive programming 9. Kumar and colleagues found hand-built workflows beat dynamically planned ones on both cost and accuracy 10.
Reliability is the stronger argument, and it is plain arithmetic. If each step succeeds with probability p and the task needs H steps in a row, the whole chain succeeds with probability:
where:
- p is the chance that one step succeeds on its own
- H is the number of steps that must all succeed
- P chain is the chance that the whole run succeeds
At 95% per step, a 20-step task finishes 36% of the time. At 99% per step it finishes about 82% of the time, and at 90% it drops to about 12% (Figure 2). Steps are rarely independent in practice, and the dependence runs the wrong way: errors grow once the model sees its own earlier mistakes in context 11.
Benchmarks that demand consistency show the same shape. On the retail half of tau-bench, success fell from about 61% on one try to about 25% when all eight tries had to pass 12. METR puts the public frontier at about 12 hours of human-equivalent work at 50% success, but only about 1.5 hours at 80% success 13. If your job has to work every night, the 80% line is the one that matters.
Sequential, tightly coupled work is the clearest loss for multi-agent designs. In the same Kim study that found the finance gain, every multi-agent variant lost between 39% and 70% on sequential planning 5. CooperBench found two coding agents working together succeed about 30% less often than one agent alone 14. Fu and colleagues compared six multi-agent systems against a single agent, and five of them trailed it, one while using 4.34 times the tokens 15.
Multi-agent setups mostly fail by design: unclear specifications, agents that disagree about who does what, and nobody checking the result. The model's raw ability is rarely the bottleneck.
MAST, from Berkeley, sorted more than 1,600 multi-agent traces into 14 failure modes under three groups: specification, misalignment between agents, and verification 16. That framing changed how I read our own incidents.
Unchecked chains amplify errors. Kim and colleagues measured independent agents amplifying errors 17.2 times, while a central orchestrator cut that to 4.4 times 5.
Parallel writers are the failure everyone repeats. Cognition argued in 2025 against building multi-agent systems at all 17, and their 2026 follow-up keeps the core of it: setups work when writes stay single-threaded and extra agents add intelligence rather than actions 7.
The gains in Figure 3 come from read-heavy work that splits cleanly. The losses come from work where each step depends on the last, or where two agents edit the same thing.
Context and memory are weaker than the "agent as staff member" picture assumes. Chroma tested 18 models and every one degraded as input grew, even on easy retrieval 18. Multi-turn conversations lose 39% on average against the same task given in one turn 19. Memory that matters belongs in files, boards and ledgers the agent reads, where you can inspect it.
Tool overload is the last trap. Shopify found tool choice turning unclear somewhere past a few dozen tools 21, and Anthropic now lists tool confusion as one of the few good reasons to split an agent at all 22.
Walk your job down the ladder in Figure 4 and stop at the first rung that holds. Most jobs stop at L0 or L1.
The rules underneath come straight from the sources. Start with one LLM call, then one agent with tools, and add agents only after a measured gain 1 6 21. Split an agent only for context isolation, tool overload or conflicting instructions 6 22. Keep one writer per artifact 7 23. Verify with rules before you reach for an LLM judge 24.
Copy this list and run it against the job you're thinking of turning into an agent:
- Can I write the steps down today? If yes, this is a workflow. Go to the next question; otherwise skip to the money question.
- Is any input free text, or does any step need a judgment call? If no, it is an L0 function or cron job. If yes, it is an L1 workflow with one typed LLM step that code validates.
- Does it touch money or irreversible state? If yes, the agent proposes and code plus a human execute.
- Does the work fit in one context, with no read-only parts that could run in parallel? If yes, it is an L2 owner agent.
- Does it overflow one context, or split into parallel parts that only read? Then it is L3, an owner with read-only helpers that return summaries.
- Does anything other than the owner write to its board, ledger or files? If yes, turn that writer into a tool the owner calls.
- Does it run often, and is the usual answer "nothing changed"? Then a script watches and wakes the agent only on a change.
- Is a second agent planned because of a new role name or topic? Fold it back in unless context size, tool count or a trust boundary forces the split.
- Do I have an eval set that shows the agent beats the script on this job? If not, run the script and build the eval first.
Yes, as far as the public cases go. In every domain I checked, the agent owns the search, the draft or the recommendation, and code or a person owns the step with a side effect.
| Domain | Agent owns | Stays deterministic | Case |
|---|---|---|---|
| Incident response | Hypotheses, root-cause drafts | Paging, escalation, runbook runs | Datadog, PagerDuty |
| IT ops | Routine ticket triage and fixes | Change policy, approvals, audit | ServiceNow |
| Customer support | Routine answers | Refunds, policy, human handoff | Klarna, CBA |
| Finance, back office | Invoice coding, approval advice | Matching, limits, ledger posting | Ramp |
| Sales and HR | Research, qualification, drafts | Sending, CRM writes, rejections | Vercel, McHire |
| Software engineering | The code change | CI, tests, merge gate | Stripe |
Incident response. Datadog's SRE agent forms root-cause hypotheses and tests each one against telemetry, and Datadog evaluates it on real incidents its teams labeled, without publishing an accuracy number 27. PagerDuty's SRE agent runs diagnostics and suggests remediation, and runs the fix on approval 28. incident.io's guide tells teams to backtest on 5 to 10 closed incidents and aim for precision above 80% with recall near 60% 29.
IT ops. ServiceNow says about 90% of its own internal IT tickets now resolve with no human, and that 85% of the people who did that work moved to other teams 30. Those are a vendor's numbers about its own product. Change policy, approvals and the audit trail stay in the platform.
Customer support. This is the mixed one. Klarna's launch release claimed 2.3 million chats in the first month, the work of 700 agents, resolution time down from 11 minutes to under 2, and repeat inquiries down 25%, all company numbers 31. In May 2025 its CEO reportedly told Bloomberg that cost had been weighted too heavily and quality had dropped, and Klarna disputes calling that a reversal. Commonwealth Bank of Australia cut 45 call-centre jobs after launching a voice bot, then reversed the cut within weeks and called its own decision an error 32.
Finance and back office. Ramp's AP agent codes invoices and recommends approvals, and Ramp claims about a 90% acceptance rate on those recommendations without defining acceptance 33. The three-way match, payment limits and posting to the ledger stay in code.
Sales and HR. Vercel took its inbound sales development team from 10 people to 1, after six weeks of shadow mode in which its top rep reviewed every output 34. The agent drafts and a person presses send. HR shows the other risk: McDonald's hiring chatbot exposed up to 64 million applicant records because an admin account around it used the password "123456" 35. The failure was in the plumbing around the agent.
Software engineering. Stripe merges over 1,000 agent-written pull requests a week, every one reviewed by a person 36. Fixed git, lint and test steps sit between the agent's steps, CI gets at most two rounds before the run stops, and each agent works in an isolated dev box.
The wins that lasted all keep an approval or a deterministic gate at the point where the side effect happens. The two pullbacks share the opposite shape: headcount went first, and quality got measured after.
Our lab had every failure the papers describe, and sorting it by rung fixed most of them on paper. Most of the work stays plain code, a handful of owner agents sit on top, and each board gets exactly one writer.
Our working rule, which the evidence backs, is that jobs own detection, money, state and scheduling, and agents own judgment and text.
The lab is a set of scheduled jobs, a few LLM steps, and about 10 owner agents spread over three clusters: personal, household and company. Each cluster has its own board of tickets, and the agents report to me through those boards.
In plain words:
- Scheduled jobs. About 88 job labels on our own machines plus 24 Worker crons in the cloud. They back things up, probe services, load data and keep tunnels open. Almost none of them calls a model.
- LLM steps. Small workflows such as our triage crews, where code gathers the input, a model returns JSON against a schema, and code checks it.
- Owner agents. One orchestrator for the personal cluster and a small set of desk agents for each of the household and company clusters. One agent per cluster answers for that cluster's board.
- Boards and ledgers. Ticket boards, ledgers and files. They are the memory, because the agents read them at the start of each run.
Five terms come up below: a cron job, the orchestrator, an idempotent action, shadow mode and an eval set. Hover or tap any of them for a one-line definition.
Before the audit, 12 separate processes could change the state of a ticket, and none of them owned it (Figure 5). Two things broke in ways nobody noticed for a while.
A sweep revived a ticket I had already dropped. A sync job archived tickets that were addressed to an agent, so the agent never saw its work. Each process was reasonable on its own. Together they were the MAST misalignment failure with no verification step 16: several actors acting on one artifact, each assuming the others knew what it did.
We put every item in one register and gave each a target rung and a move. The register came to 163 items, and most of them stay plain code (Figure 6).
By target rung, 125 items are L0 functions, 7 are L1 workflows with one typed LLM step, 19 are L2 owner-agent work, and 2 are L3 with read-only helpers. The last 10 have no target rung because they leave the register, either retired or folded into a job that survives. Only 21 items out of 163 need an agent loop at all.
By move:
- Keep, 116. Already on the right rung. Leave alone.
- Absorb as a tool, 15. The job keeps running as code, and an agent now owns its result and its status.
- Fold, 11. Merge into another item that already does the same job.
- Move to a plain scheduler, 11. Scheduled work that needs no model runs as a plain cron job.
- Retire, 7. Nothing depends on it anymore.
- Change the owner, 3. The item stays, but a different agent answers for it.
Absorbing a job into an agent is the move people misread. The job stays code and the agent calls it. From then on the agent is the one who says whether it worked and what happens next. That is how 15 jobs get an owner without spending a single extra token on the work itself.
After the moves, each cluster's board has exactly one writer, its owner agent (Figure 7). Every other process either becomes a tool the owner calls or sends the owner a proposal.
The recovery job that used to close incidents on its own will propose a close, and the owner decides. Jobs that touch money or schedules stay deterministic and idempotent, so a retry never pays twice. The rest of the mapping follows the evidence:
- The orchestrator stays a hub with spokes, the central checker that cut error amplification in the Kim study 5.
- The finance desk proposes payments and never executes them. The money path stays in code with a human gate.
- Each desk split gets checked against the split rule. A split for a different audience or a different data boundary stays. A split by topic alone folds back in.
- Our triage crews stay L1, the 12-factor shape of "mostly deterministic code, with LLM steps sprinkled in" 23. They are the easiest of our model-backed jobs to debug, so they are the template for new work.
- Our log-sweep session writes fixes in an isolated branch and gets a fresh-context review before merge, the pattern Cognition measured 7.
Follow one failure through the new setup and you can see where each kind of work lives (Figure 8). Jobs detect, the LLM step classifies, the owner decides, and I approve only what cannot be undone.
- Probe: a scheduled probe detects a failure. Plain code, same check every run.
- Intake: an intake job files a ticket on the right board.
- Triage: a triage crew asks the model for a JSON verdict, and code checks it against the schema before recording it on the ticket.
- Owner reads: the owner agent reads the ticket and the triage note and decides what to do.
- Fix: the owner proposes a fix, or runs one through a tool that is safe to retry.
- Report: the owner sends me one report, and I approve anything irreversible.
- Recovery: once the probe goes green, the recovery job proposes a close.
- Close: the owner closes the ticket. It is the only process that changes the ticket's state.
Filing a ticket and attaching a triage note add information. Only step 8, and any state change the owner makes in step 5, alter what the ticket says about the world.
Our sweep already follows the "script watches, wakes the agent only on a change" rule, and Figure 9 shows what it would cost without it. The jobs that still start the model on every run are seven low-frequency reports.
The sweep fires every 15 minutes. Before any model starts, the engine runs a monitor: a small script lists the inbox, the engine hashes that output, and when the hash matches the last tick or the output is empty, the model run is suppressed at zero tokens.
The gate had one hole until a patch in October 2026. Each time the inbox went from busy to empty, the output changed, so the model woke up only to report that there was nothing to do. The patch counts empty output as no change.
On a bare timer, the same sweep would run 96 times a day at 15,000 to 90,000 tokens each, which is 1.44 million to 8.64 million tokens a day. Those figures are computed from the per-run range, not measured. With the gate, cost follows new tickets instead of the clock. At 90,000 tokens a run, the gated sweep reaches the timer's cheapest day only at 16 new tickets a day, and at 15,000 tokens a run it would take 96, one per tick.
Seven jobs in the lab still start the model every time they fire, with no gate: daily, weekly and monthly report jobs. They run rarely, so the cost is small. Where a report's output is fixed, it is a candidate to move to a plain scheduler, one of the 11 moves of that kind in the register.
These moves are decided and partly in flight. The sweep gate is the one change already live, and I don't have lab-level before and after numbers yet. The first number I'll report is how many ticket state changes come from anyone other than a board's owner. That count should reach zero.
Grow the agent around the old system one decision at a time, and keep the legacy path in charge until the numbers say otherwise. Autonomy goes up a level only when an eval shows the current level works.
The shape is the strangler fig pattern from Microsoft's architecture guidance: a facade routes each request either to the legacy path or to the new one, and rollback stays possible until the legacy part is retired 37. For agents, the tool layer is that facade.
The autonomy levels come from Feng, McDonald and Zhang at the Knight First Amendment Institute, who name each level after the human's role 39. Autonomy rises in this order. As operator the human decides and the agent assists. As collaborator the two share the work. As consultant the agent leads and consults the human. As approver the agent acts and asks for approval on high-risk steps. As observer the human only watches, and the agent runs with full autonomy. Read-only and shadow runs sit at operator. One gated action is approver. Observer comes last, and only on evidence. The authors warn that the approver level fails quietly when people rubber-stamp what they are shown.
The sequence the sources support:
- Pick one decision point: choose one narrow decision inside a workflow you already run, and keep the legacy path as the authority for it 37.
- Wrap what you have as tools: turn existing scripts and APIs into typed, least-privilege tools the agent calls. Stripe routes its agents through one shared tool server with more than 400 tools 36.
- Build the eval set first: collect closed cases with known answers and set precision and recall targets before the agent runs, as incident.io's backtest guide does 29.
- Run read-only, then shadow: stay at operator level while a person grades every output for a fixed period and compares it with what people decided. Vercel ran six weeks of shadow mode 34.
- Enable one reversible action behind a gate: move that one action to approver level, gate every irreversible action, and cap retries. PagerDuty runs a fix on approval 28, and Stripe stops after two CI rounds 36.
- Keep orchestration deterministic: the agent is one node that returns control, and durability, audit and replay stay in the engine. Camunda calls the agent "a process step with brains" 38, and Temporal runs model calls as activities inside deterministic workflow code 40.
- Expand only on measured evidence: track false approvals and rubber-stamping, and hold headcount until quality is proven. Klarna and Commonwealth Bank show what happens in the other order 31 32.
The sweep gate in our lab is step 6 in miniature: a script owns the schedule and hands the agent control only when there is work.
No source I read compares an agent against a pipeline on the same business task, head to head. Every number above comes from a specific benchmark in a specific domain, and the multi-agent results flip sign depending on whether the task decomposes. Use them to pick what to test on your own job.
Much of the practitioner evidence comes from vendors, and vendors have a stake. Anthropic sells the tokens a multi-agent system burns, Cognition sells a coding agent, and LangChain sells a framework. The domain cases lean the same way: ServiceNow, Klarna, Ramp and Vercel report their own results, and Datadog publishes no accuracy number at all. I weighted those below the papers and kept them where an independent result points the same way.
The sources also disagree on the default. LangChain now tells builders to start with an agent harness and drop down to graphs only when they need control 25. The 12-factor authors and OpenAI say start deterministic 23 6. Dex Horthy described shutting down an unreviewed agent coding setup after four months of production breaks 26. I lean toward the deterministic default because our jobs run unattended and touch money, and a team doing mostly interactive research might reasonably lean the other way.
Our own numbers are aggregate and partial. Our estate is one team's lab, the fixes are recent, and the token figures are computed from a per-run range, not measured. I'm publishing it with those gaps marked.
If you read one book on this, read Victor Dibia's Designing Multi-Agent Systems (2025). It treats workflows as a first-class option and covers when a single agent wins. Dibia built AutoGen, so expect that lean.
The rest of the shelf, in the order I'd read it:
- Chip Huyen, AI Engineering (O'Reilly, 2025): evals, cost and latency. Without evals you can't tell whether an agent beats a script.
- Sinan Ozdemir, Building Agentic AI (Addison-Wesley, 2025): runs from workflows to agents, the same order as this question. Few reviews yet.
- Matthew Skelton and Manuel Pais, Team Topologies, 2nd edition (IT Revolution, 2025): narrow roles, clear interfaces and cognitive load, the best template I know for the "agents as staff" idea.
- Michael Nygard, Release It!, 2nd edition (Pragmatic, 2018): timeouts, circuit breakers and bulkheads, which is where the deterministic guardrails go.
- Anthropic: Building effective agents, engineering guide that separates workflows from agents, 2024-12. Building effective agents.Cited in 1, 2, 3
- LangChain: Harrison Chase, essay placing agentic systems on a spectrum, 2025-04. How to think about agent frameworks.Cited in 1
- Willison: Simon Willison, working definition of an agent as tools in a loop, 2025-09. I think agent may finally have a widely enough agreed upon definition to be useful jargon now.Cited in 1
- Anthropic: multi-agent research system, lead agent with parallel subagents, 90.2% gain and token costs, 2025-06. How we built our multi-agent research system.Cited in 1, 2
- Kim: Kim et al., Google and MIT, controlled study of multi-agent gains and losses by task type, 2025-12. arXiv 2512.08296.Cited in 1, 2, 3, 4
- OpenAI: practical guide, when to build an agent and when a deterministic solution suffices, 2025. A practical guide to building agents.Cited in 1, 2, 3, 4, 5
- Cognition: Walden Yan, single-threaded writes and clean-context review in production, 2026-04. Multi-Agents: What's Actually Working.Cited in 1, 2, 3, 4, 5
- Agentless: Xia et al., fixed pipeline on SWE-bench Lite with no agent loop, 2024. arXiv 2407.01489.Cited in 1
- AlphaCodium: Ridnik et al., flow engineering for code generation, 2024. arXiv 2401.08500.Cited in 1
- Kumar: Kumar et al., hand-built against dynamically planned workflows on cost and accuracy, 2026. arXiv 2606.00189.Cited in 1
- Sinha: Sinha et al., long-horizon execution and errors that grow from self-conditioning, ICLR 2026. arXiv 2509.09677.Cited in 1
- tau-bench: Yao et al., tool-agent benchmark with the pass-all-k consistency metric, 2024. arXiv 2406.12045.Cited in 1
- METR: frontier risk report, time horizons at 50% and 80% success, 2026-05. Frontier Risk Report.Cited in 1
- CooperBench: Stanford, two cooperating coding agents against one, 2026-01. arXiv 2601.13295.Cited in 1
- Fu: Fu et al., six multi-agent systems compared with a single agent on accuracy and tokens, 2026. arXiv 2606.05670.Cited in 1
- MAST: Cemri et al., taxonomy of 14 multi-agent failure modes from 1,600+ traces, 2025. arXiv 2503.13657.Cited in 1, 2, 3
- Cognition: Walden Yan, the case against parallel multi-agent writers, 2025-06. Don't Build Multi-Agents.Cited in 1
- Chroma: context rot report, 18 models tested on retrieval as input length grows, 2025. Context Rot.Cited in 1, 2
- Laban: Laban et al., LLMs get lost in multi-turn conversation, ICLR 2026. arXiv 2505.06120.Cited in 1
- LongMemEval: Wu et al., benchmark for long-term memory in chat assistants, 2024. arXiv 2410.10813.Cited in 1
- Shopify: Sidekick engineering post, lessons on tool count and multi-agent timing from a production agent, 2025-08. Building production-ready agentic systems.Cited in 1, 2
- Anthropic: Applied AI, when to fold subagents into one agent loop and when a split still pays, 2026-10. When to fold subagents into your main agent loop.Cited in 1, 2
- HumanLayer: 12-factor agents, principles for production LLM software, 2025. 12-factor agents.Cited in 1, 2, 3
- Anthropic: Claude Agent SDK, agent loop design and rule-based verification before LLM judges, 2025-09. Building agents with the Claude Agent SDK.Cited in 1
- LangChain: guidance to start with an agent harness and add graphs for control, 2026-08. Deep Agents vs LangChain vs LangGraph.Cited in 1
- Horthy: Dex Horthy with Gergely Orosz, The Pragmatic Engineer, an unreviewed agent coding setup shut down after production breaks, 2026-07. Context engineering with Dex Horthy.Cited in 1
- Datadog: Bits AI SRE, hypothesis-test loop over telemetry, evaluated on labeled real incidents, 2026-01. How we built an AI SRE agent that investigates like a team of engineers.Cited in 1
- PagerDuty: SRE Agent, diagnostics and suggested remediation that runs on human approval, 2025-10. PagerDuty H2 2025 release.Cited in 1, 2
- incident.io: backtesting AI root-cause analysis on closed incidents with precision and recall targets, 2026-02. AI root cause analysis: accuracy testing guide.Cited in 1, 2
- ServiceNow: reported by CX Today, a vendor running agentic AI on its own IT and HR service desks, 2026-05. ServiceNow ran agentic AI on itself.Cited in 1
- Klarna: company launch numbers for its AI customer service assistant, 2024-02. Klarna AI assistant handles two-thirds of customer service chats in its first month.Cited in 1, 2
- CBA: Commonwealth Bank of Australia, reported by ABC News, 45 call-centre job cuts after a voice bot, reversed and called an error, 2025-08. Commonwealth Bank backtracks on AI job cuts.Cited in 1, 2
- Ramp: AP agents, vendor launch of invoice coding and approval recommendation agents, 2025-10. AP just became autonomous.Cited in 1
- Vercel: interview on SaaStr, inbound sales development team moved from 10 people to 1 behind a lead agent, 2026-01. Vercel took a 10-person SDR team down to 1.Cited in 1, 2
- McHire: reported by TechCrunch, hiring chatbot admin account protected by the password 123456, 2025-07. AI chatbot's simple 123456 password risked exposing data of McDonald's job applicants.Cited in 1
- Stripe: Alistair Gray, unattended coding agents with deterministic steps, human review and isolated dev boxes, 2026-02. Minions: Stripe's one-shot, end-to-end coding agents.Cited in 1, 2, 3
- Microsoft: Azure Architecture Center, the strangler fig pattern for incremental migration behind a facade. Strangler Fig pattern.Cited in 1, 2
- Camunda: Joyce Johnson, deterministic process logic with the agent as one bounded step, 2026-01. Guardrails and best practices for agentic orchestration.Cited in 1
- Knight: Feng, McDonald and Zhang, Knight First Amendment Institute, five autonomy levels named after the human's role, 2025-07. Levels of Autonomy for AI Agents.Cited in 1
- Temporal: deterministic workflow code with model and tool calls as replayable activities, 2025-11. Of course you can build dynamic AI agents with Temporal.Cited in 1, 2
- Cron: a scheduled job that runs on a fixed timetable, such as every 15 minutes, and does the same thing on each run.
- Orchestrator: an agent that receives work, routes it to other agents or jobs, and checks what comes back.
- Idempotent: an action that gives the same result whether it runs once or several times, so a retry is safe.
- Shadow: shadow mode, where an agent works alongside the current process and people grade its output, but nothing it produces takes effect.
- Eval: an eval set, a collection of past cases with known right answers, used to score an agent before and after a change.