Every founder we talked to this quarter asked us the same thing, framed five different ways. They want AI agents in their business. They have a budget. They have a board slide. What they do not have is a clear picture of what an agent is supposed to do once it is wired into a real workflow, and which of the demos they saw on a Tuesday morning would survive a Wednesday afternoon in production.
We have shipped AI agents for clients across industries across the last eighteen months. Some of them earn their keep. Some of them quietly cost more than the salary of the person they were supposed to free up. The difference is almost never the model. It is the shape of the work around the model.
This is the field report. Three patterns we trust, the production checklist we run before anything ships, and an honest look at what AI agents for business actually do when the slideware ends.
The chatbot trap
The first thing most teams build, and the first thing most teams should not build, is a chatbot. A box on a website where a user types a question and the model types back. It demos well in a board meeting. It almost never moves a business metric.
The trap is that a chatbot puts the model on the critical path of the user experience without a clear job. The user asks something, the model answers, and now what. There is no structured output to verify, no downstream system to trigger, no human in the loop, no clear success criterion. You measure the thing by reading transcripts and feeling vaguely good about them.
We have stopped building these except as a layer on top of something that already works. A chatbot is a useful surface for a system that already automates a workflow. It is a terrible substitute for one.
What an agent actually is
An agent, in the way that matters for a real business, is a small program that takes an input, calls a model one or more times with structured prompts, optionally calls tools, and produces a structured output that another system can consume. The model is one component. The orchestration around it is most of the value.
The useful agents in our portfolio all share three properties. They have a tight input contract. They have a tight output contract. They live inside a workflow where the output triggers something specific: a human review, a database write, a webhook to another service. None of them are open-ended conversations. The conversation, if any, is an implementation detail.
This is also where the discipline overlaps with the engineering work we wrote about in our notes on vibe coding. The model is a powerful but unreliable component. Production work is in the constraints you build around it.
Pattern 1: document processing
This is the pattern with the clearest return on investment, and the one we recommend first to almost every client who comes to us with an AI brief. A document arrives. The agent extracts structured data from it. The data goes somewhere useful. Done.
The work the agent saves is not glamorous. Invoice line items into an accounting system. Contract clauses into a review queue. KYC documents into a compliance database. Email attachments into a CRM. Each of these tasks has the same shape: messy human input, predictable structured output, and a human who used to do it by hand at a rate that scales linearly with volume.
| Task | Manual hours/month (illustrative) | Agent hours/month (illustrative) | Saving (illustrative) |
|---|---|---|---|
| Invoice data extraction | 40h | 2h | ~95% |
| Contract clause review | 30h | 4h | ~87% |
| Weekly report generation | 12h | 0.5h | ~96% |
All figures are illustrative estimates only. Real numbers depend on document complexity, error rates, and how much of the saved time is reabsorbed by review. The point of the table is not the percentages. It is the shape: a task that scaled with headcount stops scaling with headcount.
The thing that makes this pattern work is that the output is structured and the failure mode is loud. If the agent misreads an invoice amount, the downstream system fails a validation rule. If a clause comes back with the wrong label, the human reviewer notices in seconds because they are looking at a queue of labelled items, not freeform text. You do not need the model to be perfect. You need the system around it to catch what the model gets wrong.
Pattern 2: async decision support
The second pattern we trust is async decision support. The agent does not make the decision. It prepares it. A human approves or rejects. The action happens after the human gate.
This is the pattern that most cleanly handles the cases where you cannot afford a wrong answer but the volume of work is high enough that doing it from scratch is expensive. Fraud review. Loan adjudication. Refund approvals over a threshold. The agent reads the case, summarises the relevant facts, proposes a recommendation with reasoning, and drops it into a queue. The reviewer spends thirty seconds where they used to spend ten minutes.
The temptation, once this is working, is to remove the human gate for the easy cases. Auto-approve anything the agent labels high confidence. Sometimes this is fine. In regulated domains, it is almost never fine without a long observation period, a written policy, and a real audit trail. We have seen teams skip straight to full automation and discover, six months later, that the agent was quietly approving a category of cases it should have flagged. The losses were not catastrophic. The trust damage was.
Our rule with clients is simple. Keep the human gate until you have at least three months of side-by-side data showing the agent agrees with the human on the boring cases. Even then, sample a percentage of auto-approved cases for human review forever. The cost of that sampling is small. The cost of not knowing the agent has drifted is large.
Pattern 3: internal tooling
The third pattern almost never makes the press release, which is part of why it works. We build agents that sit inside the company, used by employees, that make a small slice of someone's job faster. A search interface over a knowledge base that returns the answer instead of a list of links. A code review assistant that flags missing tests and proposes them. A meeting summariser that turns transcripts into structured action items in the project tracker.
These agents have three big advantages over anything customer facing. The users are forgiving. The feedback loop is fast. The failure cost is contained. An engineer using an internal tool that hallucinates can spot the problem in seconds and route around it. A customer using a public chatbot that hallucinates writes a screenshot on social media and ruins your week.
If we had one piece of advice for a founder starting their first agent project, it would be this: build the internal tool first. You will learn how the model behaves on your data. You will learn what your team trusts and what they do not. You will learn what your evals need to cover. By the time you are ready to put an agent in front of customers, you will know things you cannot learn from a demo.
What every production agent needs
Independent of which pattern you pick, the production-readiness floor is the same. Every agent we have shipped that survived contact with real usage has these ten properties in place before launch. Every agent that failed in production was missing at least three.
- Structured output schema (not free text).
- Evals: automated tests on representative inputs.
- Fallback to human when confidence is low.
- Observability: every call logged with input, output, latency, cost.
- Cost cap: hard limit per session or per day.
- Retry and backoff for transient failures.
- Audit trail: who triggered the agent, what it did, when.
- Graceful degradation: system still works when agent is unavailable.
- PII handling: know what personal data touches the model.
- Incident runbook: what to do when the agent produces nonsense.
None of this list is exotic. It is the same operational hygiene any production service needs, plus a few items that are specific to systems with a probabilistic component. The reason teams skip it is that AI features are usually pushed by product, sized like marketing experiments, and shipped without the engineering scaffolding that any other system at the same blast radius would get. That is the mistake.
The cost cap is the one we beg every client to put in on day one. The default behaviour of a buggy agent is to retry, to loop, to call the model again and again until something works or the request times out. Without a hard ceiling per session and per day, a single bad input or a single regression in the prompt can quietly burn a month of budget overnight. We have seen it happen at clients who would never have let a database query run unbounded. The model is a database query. Treat it that way.
How to start
If you are a founder reading this and trying to figure out where to begin, here is the short version. Pick one workflow inside your business that is high volume and low risk. Document processing for an internal team is the right shape almost every time. Define the input. Define the output. Define what success means in a number you can measure.
Build the smallest possible version. Wire it into a real workflow with a real human reviewing the output. Run it for a month. Look at the logs. Find the cases the model gets wrong and ask whether the fix is a better prompt, a better schema, a different model, or a different process. Most of the time, it is the schema or the process.
Once that one workflow works, the second one is much easier. The hardest part of the first AI agent in a business is not the model. It is everyone agreeing on what the agent is supposed to do, and what it is allowed to do without asking. Once that conversation has happened once, the next pattern slots into the same shape.
We are happy to talk through where an agent might fit in your business, or to tell you honestly that it does not. Half the calls we take on this topic end with us recommending the client not build an agent at all and fix the upstream process instead. That is not the answer the deck promised. It is usually the right one.