I wrote one field guide for two people who could not run more different businesses.

My son is a business litigator in Miami, a small practice where the billable hour is the whole economy. My wife runs the Carnivore Market, a retail shop where the economy is inventory, orders, and a phone that rings while she is elbow-deep in a cooler. Both of them asked me the same thing this year, in almost the same words: where does one of these AI agents actually fit in what I do?

So I built them a guide. Not a strategy deck. A field guide: how to find the job worth handing to an agent, how to build the smallest version that helps, and how to know it is working before you trust it with anything.

Here is the uncomfortable part. That guide, written for a law office and a butcher counter, is more disciplined than most enterprise AI strategy I read. Not more sophisticated. More concrete. And the gap between the two is the whole point of this post.

Agents sell work, not software

Start with the reframe, because everything downstream depends on it.

SaaS sold you software. You bought a dashboard and a login, and then your team did the work inside it. An agent sells the work itself. The customer for the new thing is not a user clicking around a screen. It is the job that used to require the user.

My wife does not want a better point-of-sale dashboard. She wants the missed calls answered and the wholesale orders entered. My son does not want another legal research subscription. He wants the first-pass document review done so he can spend his hours on judgment. Neither of them is shopping for a tool. They are trying to retire a specific piece of toil.

The enterprise version is identical and almost nobody frames it that way. Inside your company you are not buying seats. You are deciding which repeated work your people should never have to do by hand again. The unit of value is the workflow, not the license. That single shift, from tool to work, is where the leverage lives, and it is the same insight underneath why judgment is the new moat: when execution is cheap, the scarce skill is knowing which work is worth removing.

Start with the paycheck, not the platform

Here is what my wife did that your AI program probably did not. She started with a paycheck.

She did not ask what AI can do. She asked which job she already pays someone to do, all day, that she would happily stop paying for. That question is a filter, and it is brutally effective. If a real human is already being paid to do the work, three things are already true: the work is valuable enough to fund, it happens often enough to notice, and someone can tell you exactly what “done” looks like.

Contrast that with the enterprise ritual. Most large AI programs open with a platform decision and an “opportunity assessment,” a workshop that produces a heat map of forty possible use cases ranked by a committee that has never done any of them. It starts with the technology and works backward toward a job. The shop owner starts with the job and never has to work backward at all.

The field guide scores each candidate workflow the same way, and the criteria transfer straight to the enterprise without a single edit:

• Frequency. Does the job happen daily, ideally on every event? A weekly task is a nice-to-have. A task that fires on every call, ticket, invoice, or claim is a business case.
• Pain. Does the owner feel the loss in their body? The ones who name a dollar figure or tell you a horror story unprompted are the ones who will fund the fix.
• Finish line. Is “done” unambiguous? Booked, categorized, approved, reconciled. Binary outcomes are buildable. “Improve the experience” is not.
• Tool access. Can you actually reach the systems the job touches? Phone, inbox, calendar, CRM, the claims system. If you cannot integrate, you cannot automate.
• Budget owner. Can you name the person who signs off, and do they already pay a human for this? If yes, you are not selling a science project. You are offering to lower a line item they already carry.

Notice what is missing from that list: the model, the framework, the vendor. None of it matters until a workflow passes all five. And most of the enterprise toil worth automating is not even code. As I argued in why the bottleneck was never the code, the paid work that eats the day is the coordination, the triage, the follow-up. That is the work with a paycheck attached.

Shadow the human, because the moat is the exception

The step everyone wants to skip is the one that makes the whole thing defensible. Before you build anything, watch a real person do the job ten or twenty times. Have them narrate. Ask what makes a case easy, what makes it weird, where the mistakes happen.

A butcher-counter clerk answering “do you carry ribeye” is doing far more than reading a stock level. They know which regular wants it cut thick, that the good briskets land on Thursday, which standing orders get pulled before the shelf is even filled, and how to handle the customer who asks for a discount every single time. That tacit knowledge is not in any system. It lives in a person.

Your enterprise runs on the exact same hidden layer, and it is worth more to you than it was to the shop. The happy path of any workflow is a commodity that anyone can prompt in an afternoon. The value is in the exceptions: the escalation nobody documented, the account that gets handled differently for reasons only a fifteen-year veteran remembers, the compliance carve-out that lives in one person’s head and walks out the door when they retire. Shadowing is how you capture it before it leaves. Treat “watch the human” as institutional-knowledge capture, not requirements gathering, and it becomes the most valuable hour your program spends. It is also the surprise waiting for every team that skips it, the same lesson five engineers learned the hard way in what happened when they started building.

Run it manually before you build anything

My son validated his document-review idea without writing a line of code. He copied the context into Claude, drafted the output, and checked it by hand against what he would have done himself. Twenty times. By the end he knew exactly where it helped, where it drifted, and what a good answer even looked like.

That is the cheapest de-risking available and enterprises skip it constantly, because “run it by hand in a chat window” does not sound like a strategy. It is one. You are testing whether AI helps at all before you spend a cent on engineering, and you are writing the specification as a natural byproduct. By the time you have done the job manually a dozen times, you can write the whole spec on one page: the trigger that starts it, the context it needs, the tools it touches, the rules it must never break, the handoffs to a human, and the eval that says it worked.

This is the reconciliation instinct applied before the build instead of after it: define what “ideal” looks like, measure the gap, close it. I made that case for the runtime in the reconciliation loop. Doing it by hand first is the same loop, run once, for free, with a human in the chair.

The autonomy ladder is two axes, not one

Now the part people get backwards. Everyone hears “agent” and pictures a fully autonomous digital employee. Those are the demos that dazzle and the deployments that fail. Real agents come in shapes, and the shapes form a ladder you climb one rung at a time.

• Draft and approve. The agent reads the context and writes the reply, the quote, the memo. A human signs off. Best when there is real risk or real creativity in the output.
• Triage. The agent classifies incoming work and routes it to the right person or queue. Humans still execute. The agent removes the coordination tax.
• Coordinator. The agent runs multi-step work across several tools, with human checkpoints at the risky moments.
• Bounded action. The agent acts alone, under strict rules. The canonical example is a food-delivery app auto-refunding a missing item with no human in the loop. Earned, never assumed.

That ladder measures one thing: capability, meaning what the agent is allowed to do. And this is where the enterprise conversation needs a second axis it usually forgets. Capability is not the same as oversight. How much you watch is a separate decision from how much the agent does, and it has its own ladder. I built that one already in the trust ladder, five levels of oversight from full human control to genuine autonomy, each with graduation criteria. Read the two together: one ladder is what the agent may do, the other is how closely you supervise it. A high-capability agent under heavy oversight is perfectly reasonable. A low-capability agent nobody watches is how you get quietly burned.

The capability shapes map cleanly onto the patterns Anthropic named in Building Effective AI Agents: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. Their central rule is the one enterprises most need to hear: start with the simplest thing that works, and add complexity only when it delivers measurable value. A workflow follows a predictable, coded path. An agent decides dynamically. Most problems that get pitched as agents should start their life as workflows.

The reason is math, not taste. Anthropic’s own multi-agent research system beat a single agent by 90.2% on their internal eval, and it burned roughly 15 times the tokens to do it. Token usage alone explained about 80% of the performance difference. Multi-agent wins when the value of the task clears the cost of the tokens, and loses badly when it does not. That is the same discipline I laid out in Agent as a Service Is Real. The Vendor Pitch Isn’t.: prefer the single, monolithic agent until coordination value genuinely exceeds coordination cost. I will not re-run that math here. I will only insist you do it before you buy the multi-agent story.

Evals are the gym and the business case

Before you promote an agent one rung up either ladder, build a test set: fifty real examples of the job with the right answers marked. Every time you change the prompt, the model, the tools, or the workflow, you run the set and you know, in numbers, whether you made it better or worse. That is the gym. It is how the agent gets strong enough to earn the next rung.

In the enterprise it is also something the field guide never needed: your business case. My wife trusts a demo. Your risk committee does not, and it should not. “We ran it on fifty real maintenance tickets. It routed forty-two correctly, flagged six for review, made two mistakes, and here is exactly how we fixed them.” That sentence is worth more than any vendor slide, because it turns “trust me” into evidence. It is how you get sign-off from the people whose job is to say no.

It also fixes a structural problem I described in the gate was built for a human: human-speed review cannot keep up with machine-speed output. The eval set is the gate rebuilt at machine speed. It is the only control that scales as fast as the thing it is controlling.

The wrapper is the product

The agent itself is almost invisible. It lives inside the phone system, the inbox, the ticket queue, the claims platform. Nobody sees it work. What you actually build, and what people actually trust, is the wrapper around it: the logs, the approval steps, the handoff rules, and a way to test it before it goes live.

For my wife’s shop, the wrapper is dead simple: call summaries, which orders got captured, and which calls the agent handed to a human. For the enterprise, the same control room is what makes the thing auditable and, just as important, adoptable. People who have never trusted an agent before need to see exactly why it did what it did, in language they understand, not a stack trace. The harness is the part that compounds, which is the argument I made in six primitives for a code factory: you own the chassis and rent the engine. The model will be replaced next quarter. The control room you build around it is the durable asset.

Where the field guide breaks at scale

I owe you the honest part, because the extrapolation is not clean.

The field guide assumes one owner who can watch a demo, feel the pain, and say yes on the spot. That is its superpower and it does not survive contact with the enterprise. Inside a large company the decision is a committee, the data has boundaries and residency rules, procurement has a calendar of its own, and every workflow you touch has a compliance shadow the shop owner never had. The “move fast because one person decides” energy is exactly the part that does not transfer.

Neither does the back half of the original guide. I wrote my son and wife a whole section on selling pilots, pricing, and marketing the agent to customers, because they might build a small business out of this. Internally, none of that applies, so I left it out on purpose. “Sell three pilots in a niche” becomes “secure one sponsor and one budget line.” The distribution playbook becomes a change-management problem.

And the deepest limit is one no field guide solves: you cannot write a deterministic unit test for a system that reasons a little differently every time it runs. Evals narrow the uncertainty. They do not eliminate it. Anyone who tells you they have made agents fully predictable is selling you the same fantasy as the fully autonomous digital employee.

What does transfer, cleanly and completely, is the front half. Start with the paycheck. Shadow the human. Run it by hand first. Build the smallest useful version. Gate every promotion with evals. That discipline is domain-independent, and it is precisely the discipline the expensive programs skip.

---

Your enterprise does not need a bigger AI strategy. It needs the shop owner’s question: what job do we pay for, all day, that repeats, and what would it take to make it disappear?

If you want the infrastructure and cost side of this, Agent as a Service Is Real. The Vendor Pitch Isn’t. covers the stack and the math, and the trust ladder is the oversight axis this whole method plugs into.

I write about AI-assisted development, enterprise architecture, and the infrastructure layer between them. Find me on X @orestesgarcia or LinkedIn /in/setsero.