Building applied AI products: jobs, patterns and the platform underneath

Pick the main job from the nine, then list any others. Fin is a Serve product with a Know job inside it. Each job brings its own default autonomy and its own way of going wrong, so I'd treat adding one to an existing app as a launch of its own.

What "done" means. Each job has its own end state. Build: a merged or published change that passes checks. Know: a correct answer with sources the asker may see. Do: the other system's state changed correctly. Create: something the user keeps. Serve: the problem solved, or handed to a person with context. Decide: a decision that can be explained and appealed. Watch: the right person told, with evidence. Capture: a record correct enough to trust, or flagged for review. Govern: a policy enforced, with a record that it was.

Who's affected. Users and affected people aren't always the same. Capture and Decide touch people who never open the app: others on a recorded call, the applicant whose CV was screened. A class action filed in 2025 alleges that Otter's meeting assistant recorded people who never agreed to it (pending as of April 2026). Granola made the opposite choice: no bot joins the meeting.

The never list. Write the handful of things the app must never do. They become the first hard cases in phase 4 and the first permission checks in phase 5. For the contracts assistant: never state an amount owed without citing the clause, never show a contract to someone who can't open it in the CRM, and never describe a policy the library doesn't contain. Air Canada learned the last one in front of a tribunal (Examples).

Real examples. Before anyone builds, collect about 20 real instances of the work with their outcomes: support questions and the answers given, deals sales ops flagged by hand. They seed the cases in phase 4, and they show whether the job is as well defined as everyone thinks. Often it isn't: two experts give different answers to the same question.

The four big guides agree on where to start. Anthropic says to find the simplest solution possible, OpenAI to use a deterministic solution when a use case doesn't need an agent, Microsoft (September 2026) to use the lowest level of complexity that reliably meets your requirements, and Google lists a single call with no agent as the right answer for predictable tasks.

The six blocks, in the order of the diagram:

1. Prompt chaining: fixed model calls in sequence, with checks in code between them: extract, check, summarize, and stop if the check fails. Fin works this way (Examples).
2. Routing: a classifier sends easy questions to a fast model, hard ones to the strongest model and some to a person.
3. Parallelization: several calls at once, merged in code, such as three searches on different sources. Anthropic says parallel searches cut research time by up to 90% on complex questions in its own system.
4. Orchestrator and workers: a model splits the task into subtasks nobody could list in advance, hands them to workers and combines the results. Anthropic's research system works this way and uses about 15 times the tokens of a chat.
5. Evaluator and optimizer: one model produces, another grades, and failures go back as feedback until it passes or hits a limit. Replit's agent tests the app it built in a browser and loops through fixes.
6. Agent loop: the model picks each step itself, until it's done or hits a limit. Claude Code, OpenAI's Codex and Cursor's agent work this way.

How the agent loop works. Most agent loops are built as ReAct. The model reasons about what to do, acts by calling a tool, observes the result, and repeats until it's done or hits a limit. A support agent handling "where's my order?" might run four turns:

1. Reason: "I need the order status." Act: call the order lookup.
2. Observe: "shipped, delayed at the carrier." Reason: "I should check the new delivery estimate." Act: call the carrier tracking tool.
3. Observe: "arriving Friday." Reason: "I have enough to answer." Act: draft the reply.
4. The reply goes to the customer, and the loop stops.

The pattern comes from the ReAct paper (Yao and colleagues, October 2022), which interleaved reasoning with actions. Plan-first designs like ReWOO (2023) plan every step up front and then run them. That uses far fewer tokens, but the plan can't adjust when a tool returns a surprise like "delayed at the carrier".

What production looks like. The best data I found is small but points one way. In "Measuring Agents in Production", a study led by researchers at Berkeley and Stanford, 16 of 20 case studies of agents in production or pilot used structured workflows rather than open-ended planning, and most builders surveyed let an agent take only a handful of steps before a person stepped in. It's a small 2025 sample, so I read it as a direction. Salesforce added Agent Script to Agentforce in October 2025, mixing fixed logic and model instructions, because with model-only decisions the same request could take different routes. Sierra describes supervisor models that correct, block or escalate answers. The industry is converging on hybrids: the model gets freedom inside a path that code controls.

Where open loops win. Coding and research are the exception, and much of the money in agents is there: Microsoft said in July 2026 that GitHub Copilot had 50 million users. Tests, compilers and diffs give the loop something true to observe at every step. If your job has a cheap, reliable check at each step, an open loop can pay off. Without one, errors compound from step to step and it's hard to tell which run went wrong.

More agents isn't better, either: in one study of 180 configurations, every multi-agent variant did 39-70% worse than a single agent on sequential planning tasks.

For the contracts assistant I'd put routing in front of a chain: classify, retrieve, answer with citations, check the citations in code, and hand off to finance when the check fails. No loop. The credits job would be the first place where a model's choice leads to an action, and phase 5 decides how far it can go.

One tool call. The model only proposes the call: it returns a tool name and arguments, and nothing has run yet. A permission check in code decides whether it runs: is this tool allowed for this user, in this run, with these arguments, after what the run has already read? Then the system acts, with the user's delegated identity and a timeout. The result goes back into the model's working memory before it picks the next step. A refused or failed call is reported back to the model, which tries another way; the MCP specification returns tool errors as results the model can read and correct. The guardrail lives at the check, so I never rely on the system prompt to stop an action. Claude Code's documentation says it directly: permission rules are enforced by the tool, and instructions in the prompt change what the model tries, not what's allowed.

What decides each next step

In a ReAct loop, every single next action is shaped by nine inputs. Read them top to bottom, from the most general to the most specific; only the last one is enforced outside the model.

Items 1-7 are context: they persuade the model. Item 8 bounds what it can try. Item 9 is the only hard guarantee, so anything that must never happen belongs there (phase 5). In the six questions, items 1-7 are context, item 8 is tools and item 9 is risk. It also explains why the same model behaves differently in two apps: the training is shared, and everything below it is different.

Context, connectors and memory

Context engineering. Anthropic's September 2025 post defines it as curating everything the model sees: system prompt, tool definitions, retrieved documents, memory, the conversation and earlier tool results. Quality drops as the window fills, which Anthropic calls context rot. Start with a short system prompt, add an instruction only when a case fails, and when an answer goes wrong, look at what was in the window. Tool definitions count too: 58 tools across five MCP servers took about 55,000 tokens in one Anthropic measurement.

Retrieval. If the whole corpus fits in about 200,000 tokens (roughly 500 pages), Anthropic says you can skip retrieval and put it all in the prompt, ideally cached. Above that, or when different people may see different documents, you search. Hybrid search, combining meaning-based (embedding) search with keyword search, is the sensible default for company text, because embeddings miss exact codes, names and IDs. If missed passages are your quality problem, add context to each chunk and a reranker; in Anthropic's own test on older models that cut failed retrievals by about two-thirds.

Permissions. Retrieval has to run as the person asking. On the three big cloud stacks, source permissions are copied when the index syncs, so a change to who can see a document reaches the AI late. Microsoft's Purview runs a weekly oversharing check on the busiest SharePoint sites by default, because an assistant makes old oversharing easy to find. Test with two accounts that should see different documents.

Citations. Anthropic's and OpenAI's APIs both return citations tied to the source. A citation shows where text came from, and doesn't prove it's right, current or the asker's to see.

Untrusted text. Anything the model reads (a document, an email, a web page, a tool result) can contain text that looks like an order. OpenAI's Model Spec says quoted text, files and tool outputs carry no authority by default, yet models still can't reliably tell trusted instructions from ones hidden in content. EchoLeak, reported in Microsoft 365 Copilot in June 2025, let hidden instructions pull data out without the user clicking anything (Examples). Labelling it as data helps, but the control is in code: once a run has read outside text, it can't call a write or send tool without approval, as phase 5 explains.

MCP and connectors. MCP (the Model Context Protocol) is the shared way for an AI app to reach tools and data. The July 2026 specification says servers must validate inputs and enforce access control, and clients should confirm sensitive operations. Treat an outside MCP server like any vendor with access to your data: early 2026 brought dozens of reported vulnerabilities, and a server can change its tool list after you've approved it. AI agents: orchestration platforms and Agent identity go further.

Memory. Working memory is the context window; it's gone when the run ends, and long runs need compaction (replacing old turns with a summary). Written memory is what the app keeps across sessions: preferences, facts about an account, lessons from earlier runs. Writing it means a model deciding what to keep from text it read, the same channel prompt injection uses; one research team reported over 80% attack success after poisoning less than 0.1% of a memory store. Treat a memory write as a write action, and decide up front whose memory it is, how long it lasts and how it gets erased.

The spec is a set of cases. A traditional spec says what to build. A case says what the app must do on one input, and a set of cases says it for the inputs you care about. Each case has the input, the expected outcome (the end state, rather than the exact steps), a grader (code, a model acting as judge, or a person) and one known-good answer. Include cases where the app should act and where it shouldn't.

A refund-agent case: the order is 45 days old and the policy window is 30 days. Expected: no refund, a polite refusal that states the policy, and an offer to reach a person. Graders: a code check that the refund tool wasn't called, and a judge for tone. Writing ten of these is the product conversation about policy, tone and handoff.

When to write them. The field's best-known voices disagree on timing. Hamel Husain and Shreya Shankar answer "generally no" to eval-driven development: failures are too hard to predict, so write graders for failures you've seen, except for narrow rules like "never mention competitors". Anthropic's January 2026 guide recommends defining capabilities with evals before the agent can meet them, and also says to start from 20-50 tasks drawn from real failures and what you already test by hand. Both start from real cases rather than invented criteria, and that's the part I'd hold on to.

So I build the set in two layers. Before building, turn the real examples from phase 1 into cases and add the never list as yes-or-no checks. Once a version runs, read traces, find how it actually fails, and add cases and graders for those failures. Expect the opening layer to be wrong in places: Shankar's research with colleagues found that people discover their criteria while grading.

Graders. Use code where you can (was the refund tool called, does every claim cite a passage, did an internal ID leak), a model judge where you must (tone, accuracy of a summary), and people to check the judges against their own labels. For the contracts assistant, code covers most of it: the cited clause exists, the amount matches the clause's arithmetic, and no contract came from an account the asker can't see. A finance specialist labels the rest and keeps the judge honest.

Why the cases are the asset. Prompts are the least durable part of an AI app: Cat Wu of Anthropic wrote in March 2026 that the team cuts prompting back at each model generation, and the case set tells you which prompt text you can delete. Tools are less durable than they look: OpenAI's hosted Evals product shuts down on November 30, 2026, and teams take their datasets and graders with them. Anthropic says teams with evals can upgrade to a new model in days rather than weeks, a claim without data that matches what I've seen.

A passing set only protects you against failures you already know. In the best-documented regressions, at OpenAI in 2025 and Anthropic in 2026, the evals passed and users found the problem. Running an agent product covers error analysis, judges, release gates and the weekly quality review, and AI evals and observability covers the tools.

A setting per action. One product often offers several levels of autonomy. Claude Code has manual, plan, auto and other modes. Replit added an autonomy selector from Low to Max in September 2025, after users said its new agent did more than they wanted. I'd set a level per action, with a default per job:

Govern is a fourth case: it enforces, blocking or logging without asking anyone. Microsoft Purview can stop Copilot from summarizing documents with a sensitivity label.

A 2025 paper from the Knight First Amendment Institute makes the point I find most useful: autonomy is a design choice, separate from capability, so a very capable agent can still be set to ask first. For the contracts assistant every action is suggest. For credits I'd make drafting a credit note and applying one up to $100 act within limits (with a log), and anything above $100 act with approval by a named person in finance.

Approvals as boundaries. Per-action prompts wear out. Anthropic reports that users approve 93% of Claude Code's permission prompts, and a prompt that's nearly always approved protects very little. What holds up is a boundary in code with approval only for crossing it: a workspace the agent can write to, network off by default, protected paths, credentials scoped to the task. OWASP's guidance on excessive agency agrees: least privilege, narrow tools, and authorization enforced in the system being called rather than by asking the model.

Cost caps. A loop that doesn't stop runs up a bill. Caps exist per run (Claude Code's headless mode takes a budget and a turn limit, neither set by default), per organization (monthly spend limits in the labs' API consoles) and per design (stopping conditions in the loop). Put the cap where the unit of value is: per conversation for Serve, per run for Do and Build, per day for Watch.

Prompt injection. Nobody claims to have solved it. Anthropic says no browser agent is immune and OpenAI says it's unlikely ever to be fully solved, so the design rule matters more than any filter. Simon Willison's "lethal trifecta" is private data, exposure to untrusted content and a way to send data out. Meta's Rule of Two says an agent should have at most two of: reading untrusted input, reaching sensitive systems or private data, and changing state or communicating externally. For each job, name the leg you cut:

• Know: cut the outbound leg. The contracts assistant reads private contracts and maybe text from customer emails, so it gets no tool that sends anything or fetches arbitrary web addresses.
• Capture: it reads untrusted calls and emails by nature, so cut broad writes. It fills named CRM fields against a schema and has no tool that takes free text.
• Do: it usually keeps all three legs, so approvals at the boundary and narrowly scoped credentials carry the load.

Decide is two jobs. Decisions about a person (hiring, credit, insurance, housing, benefits) come with rules and dates. Anthropic's usage policy, effective November 12, 2026, requires a qualified person who meaningfully reviews the recommendation, with authority to change it, before it's used, plus disclosure that AI was involved. OpenAI's policies prohibit automating such decisions without human review. The EU AI Act's high-risk duties for hiring and credit scoring apply from December 2, 2027, and Colorado's narrower law from January 1, 2027. A review step that approves 93% of what it sees would be hard to defend as meaningful, so design the reviewer's screen for disagreement: the evidence, the model's reasons and an easy way to change the outcome. AI governance has the rules by region.

Decisions about transaction risk are a different, long-established kind. Stripe Radar blocks the riskiest payments automatically and sends a middle band to manual review, and merchants can test a new threshold on past payments before applying it. The EU's credit-scoring rules carve fraud detection out. I'd copy the pattern for any transaction-risk decision: a threshold, a queue for the middle band, a backtest before changing it, and a written point of no return.

The layers. Once you have more than one job, you'll notice they share most of their parts. The lab and cloud stacks (OpenAI's Agents SDK, Anthropic's Claude Agent SDK, Google's Agent Development Kit, Microsoft Foundry, AWS AgentCore) ship much the same pieces under different names; the grouping below is mine. People meet the app at the surfaces, the runtime runs each job, policy decides what may happen, context and connectors hold what it knows and touches, and events wake it up.

• Surfaces: chat, the IDE, Slack or Teams, email, voice, an API. The surface decides who the user is and where an approval can appear.
• Agent runtime: the loop that calls the model, runs tools, keeps state and stops. Model choice per step lives here.
• Policy: every action passes here. Anything that must hold, like a spending limit or who can refund, goes in code at the tool.
• Context: retrieval, memory and structured data.
• Connectors: MCP servers and APIs to the systems the app touches.
• Events: schedules, webhooks and new tickets that start a run without a person. A payload is untrusted input, and needs a key against duplicates and a rate cap.
• Traces and evals: these run through every layer. A trace is a copy of user data, and OpenAI's Agents SDK records inputs and outputs by default.
• Tenancy and control plane: under everything, each customer gets an isolated space, and someone can see every agent, its owner and its cost, and turn it off. The tenant ID on every retrieval filter, memory scope and cache key is yours to build.

One warning from Microsoft's own documentation: Copilot Studio's event triggers run with the credentials of the person who built the agent, so end users can reach that person's data through it. Check whose identity each trigger uses.

Cost per task. Cost per task = steps × tokens per step × price per token. The factors multiply, and each varies a lot: list prices differ about 100 times between the cheapest and most expensive model tiers, and reasoning effort changes one model's cost per task 5-11 times. Models and inference has the pricing detail.

Here's the contracts question from the opening in three designs. The library is 200,000 tokens and the answer about 400 tokens with two citations. Prices are list prices on October 19, 2026, and the token counts are my assumptions, so read the table for the shape rather than the cents.

The same question costs about 100 times more in A than in C. Caching helps A because its prompt is stable, and barely helps B. None of this says C is good enough; the cases from phase 4 decide that. C is wrong if the router sends hard questions to the small model, and A may be right when a question needs the whole library, though A can't show different people different contracts.

Latency follows the same logic. OpenAI's latency guide says output dominates, and thinking is output you wait for. My rough estimates are tens of seconds for A and a few seconds for B and C. Agents multiply both cost and wait, since each step sends the history again, so turn caps are cost controls.

Adding a job. A new job is a prompt, tools, a set of cases and an autonomy level, and it reuses the layers. Take the stuck-deals request, a Watch job:

• Event: a nightly schedule.
• Context: each open deal's stage, days in it, the normal range for that stage, and 30 days of CRM activity.
• Tools: read deals through the CRM connector the contracts assistant already uses, and post to the deal owner in Slack or Teams. Nothing that edits the deal.
• Prompt: decide whether the deal is stuck, say why, and suggest one next step.
• Cases: 40 past deals sales ops already labelled, including some that were slow for a good reason.
• Autonomy: suggest. The owner decides.
• Risk: activity logs include customer emails, so the only outbound tool posts inside your own workspace, under a nightly cost cap.

Everything else already exists, which is where a platform earns its keep: in my experience later jobs ship in weeks.

Build or buy, layer by layer. Anthropic advises starting with direct API calls before adopting a framework, and I'd follow that until a second job shows which pieces repeat.