BEACON: six questions to answer before your AI goes to production

The design delta — what agentic AI adds to your design work, and how to do it

Why AI needs extra design questions at all

Most enterprise AI deployments surprise their sponsors. The pattern repeats across industries. A team finds a promising workflow. A pilot is built. Results are encouraging. Leadership approves. The system goes to production. And then one of three things happens:

• The cost grows faster than the business case — because the real cost at production volume, on real messy inputs, was never what the pilot suggested.
• Wrong answers reach the outside — not obviously wrong, but confident, fluent, and wrong, and some reach customers before anyone catches them.
• The system quietly changes — the model provider ships a routine update, behaviour shifts, and nobody notices for weeks because nothing was built to notice.

None of this is bad luck. It is predictable, and it comes from one root cause: teams design AI systems using habits built for traditional software. Traditional software is deterministic (same input, same output), fixed-cost (the license doesn't care how long the document is), and stable (it doesn't change unless you change it). Generative AI is none of these three. It is probabilistic — it produces plausible output and does not know when it is wrong. It is consumptive — every word read and written is billed, so cost scales with volume and complexity. And it is evolutionary — the model underneath your system changes on someone else's schedule.

Three different properties mean the design work has a delta: a set of questions your normal design process never had to ask, because the old assumptions made them unnecessary. BEACON is that delta, organised into six questions. It is not a replacement for your development process — you still gather requirements, design, build, and test. It is the additional layer that makes an AI system safe to run and worth running. And it applies whether your build turns out to be a single model call, one agent, or a coordinated set of agents — that choice should come out of this design work, not go in before it.

The six questions, in the order you should work them:

The letters rearrange to spell BEACON. The questions are not complicated. What is genuinely hard is answering them honestly for a real workflow — because each one crosses business process, technology, data, and operations, and no single team holds all of it.

To make this concrete, we'll follow one fictional example through all six: Northline, a mid-sized retailer, wants an agentic system for refund requests. The agent reads the customer's request, checks the order, delivery and payment records, decides whether a refund is due, and issues approved refunds up to a limit. A classic agentic build: it reads, reasons, uses tools, and acts.

C — Candidacy: is this the right workflow for AI?

Why. The most expensive mistake in enterprise AI is building the wrong thing well. Candidacy exists because "AI could do this" is true of almost everything, and it tells you nothing. The question is whether this workflow, with its consequences, data, and rules, is a place where AI's strengths outweigh its nature.

What. Assess nine things, honestly, in writing: output tolerance (is there a range of acceptable answers, or exactly one right one?); consequence of error (when the AI is wrong, who sees it first — someone inside, or the customer?); reviewability (can your reviewers actually verify the output in the time the process allows?); rule stability (how often do the rules change, and are they written down anywhere?); grounding data (does the information the AI needs exist and stay current — including the procedural knowledge that today lives only in people's heads?); volume and latency (is there enough work to justify the build?); definability of good (can you write down what a correct output looks like, example by example?); regulatory exposure (do automated-decision or sector rules apply?); and differential performance (could quality differ across customer groups without anyone intending it?).

How. Run this with the business owner in the room — not just the technology team. The most important answers ("what happens when a wrong answer reaches a customer?") are business answers. Score each criterion, then make a written decision: proceed, invest first (fix the data or the rules, then return), or do not proceed. Six or more positive criteria is a good candidate. One page, signed by a non-technical owner. And Candidacy always comes first: if the workflow fails here, stop — the other five questions are not worth answering yet.

Northline. Refunds pass most criteria: high volume, documented policy, verifiable against order records. Two flags: consequence of error is external (a wrong refusal reaches an unhappy customer directly), and one rule — the "goodwill refund" — turns out to exist only in the heads of two senior agents. Verdict: invest first — write the goodwill rule down; then proceed, with the error consequence explicitly designed for, not assumed away.

E — Economics: what does it truly cost at production scale?

Why. AI is billed by consumption, so the pilot's bill tells you almost nothing. Pilots run on clean samples at low volume; production runs on the full messy distribution at full volume. Cost surprises kill more successful systems than errors do.

What. A cost model per decision — one refund resolved, not per token — built from realistic inputs: the long rambling emails, the multi-item orders, the retries, the tool calls, and, above all, the human review minutes your design demands (usually the largest cost, and never on the API bill). Then the same model at ten times the volume, with a worse case mix, because clean cases automate first.

How. Take twenty real cases, including ugly ones. Run them through a realistic prototype. Record everything consumed — model calls, retries, lookups — and estimate review time for the cases that would pause. Compute cost per decision. Compare it against what the work costs today (a useful rule from our practice: the system should come in at no more than about 70% of the loaded cost of the work it displaces, at full volume). One page: the per-decision cost, its assumptions, and the 10× projection.

Northline. The pilot's happy-path refund costs a few cents. The realistic mix — multi-item orders, missing delivery scans, photos of damaged goods — triples the model cost and, more importantly, sends 35% of cases to a human at four minutes each. The honest per-decision number is nine times the pilot estimate. Still comfortably under the 70% line — but now the business case is real, and the design team knows the ask-rate is the number to engineer down.

A — Architecture: how is reliable behaviour designed?

Why. A raw model call is a talented improviser. Reliability does not come from the model; it comes from the structure you put around it — what it reads, what shape its output must take, what checks stand between its proposal and any real effect.

What. Four design decisions. Output structure: the AI returns a defined, machine-checkable object (decision, reasons, evidence references, confidence) — never free text into a critical path. Grounding: what the AI must read before answering — which systems, which documents, how freshness is guaranteed — and for agentic builds, a deliberate context inventory: the conventions and procedural knowledge the agent needs that no document currently contains. Verification: wherever a fact can be checked without a model — an amount against an order, a date against a record — a deterministic check does it; the model proposes, something that is not a model confirms. Routing: each step gets the smallest model that passes your quality bar; the expensive model is reserved for the steps that earn it.

How. Draw the workflow as steps. For each step write: input, output schema, grounding sources, the deterministic checks, and the model tier. Where the output is consequential — money moves, a customer hears something — design the split explicitly: the model gathers, reads, and proposes; rules or a person decide. One page plus the schemas.

Northline. The agent's output is a structured refund proposal: eligibility per policy rule, amount, evidence (order line, delivery scan, payment record), confidence, and anything unresolved. The refund amount is never model-computed — it is calculated by code from the order record. The policy is retrieved from one versioned source, not pasted into a prompt. And the actual issuing of the refund is a deterministic step that fires only when the checks pass — the model never touches the payment system.

B — Boundary: what may it access, and what may it do?

Why. An agentic system is defined less by what it can do than by what it is permitted to do. Boundaries decided "later" become incidents. And in AI, boundary is a two-sided question: what data flows into the model (and to which provider, under which agreement, in which jurisdiction), and what actions flow out.

What. On the data side: a classification of every input — can customer payment details go to this provider? Under what data-processing agreement? With what retention? On the action side: an explicit permission list, machine-enforced — every action the system can take sorted into act (alone), ask (pause for a person), or stop (never), with hard caps expressed as rules, not intentions. The test of a real boundary: it is written as configuration the system enforces, so the model cannot be talked out of it.

How. List every data element the system touches and every action it could take. Classify both. Write the caps as numbers. Have someone who owns risk sign the page. Then implement it as enforcement outside the model — checks that run before and after, whatever the model says.

Northline. Data: order and delivery records may go to the model; stored card numbers never do (the payment reference is enough). Actions: refunds up to ₹5,000 on fully verified evidence — act; ₹5,000–25,000 or any unresolved evidence — ask; above ₹25,000, suspected fraud patterns, or any account flagged in a dispute — stop, to a person, with no model recommendation attached. The caps live in configuration; changing one is a recorded, attributable act.

O — Oversight: what is the genuine human role?

Why. Almost every AI plan says "a human reviews it." Almost no AI plan designs the review. The result is nominal oversight: a busy person facing a queue of fluent, confident drafts, approving in seconds. That is not a safety layer; it is a rubber stamp with a salary — and when something goes wrong, that person carries blame for a review they were never given the means to perform.

What. For every pause the Boundary design creates: a named person (a role held by a person — never "the team"), a clock (expected response time, visible), the reason shown (the reviewer sees which check failed and what evidence is missing — not a transcript to re-read), and a recorded outcome (the decision and its reasoning, captured, feeding the system's precedent). Plus one honesty check back to Candidacy: can this reviewer actually verify the output — do they have the knowledge, the access, and the time?

How. Design the review screen before the agent. If you cannot design a review a person can genuinely perform in the time available, the step does not belong in ask — it belongs in stop, or the workflow needs redesign. Then measure reviews in production: an average approval time of twelve seconds is not oversight, and it is a design finding, not a people problem. One page: the review-point map, names, clocks.

Northline. Mid-band refunds go to one of two named senior agents, on a two-hour clock, on a screen that shows: the policy rule applied, the evidence found, the one thing unresolved. Reviews average ninety seconds and the reviewers can defend every decision — because the system did the assembling and the human did the judging. Their decisions accumulate: when the same unresolved pattern is decided the same way twenty times, that pattern becomes a candidate for a new deterministic rule.

N — Navigation: how will you know it is still right in six months?

Why. Everything so far describes the system on day one. But the model will be updated, your data will drift, your policy will change — and an AI system fails silently, by staying fluent while becoming wrong. Navigation is the discipline that makes change safe and drift visible.

What. Four mechanisms. A golden set — real cases with known-correct outcomes (start with 25 well-chosen ones; grow toward 50 and beyond from production mistakes) that the system is scored against on a schedule and before any change. A pinned baseline — you control when the model version changes, and every migration re-runs the set before it ships. Drift watch — tracking the ask-rate, the refusal rate, cost per decision, and outcomes across customer segments (the differential-performance risk from Candidacy, now monitored, not assumed). And a withdrawal rule: when the golden set stops passing, the system falls back from acting alone to proposing for a person, automatically, until the score recovers.

How. Build the golden set during design, not after launch — Candidacy's "definability of good" criterion already forced you to write correct answers down; keep them. Wire the set to your release process: a change that drops the score does not ship. Assign an owner, the way month-end close has an owner. One page: the evaluation plan, the schedule, the thresholds, the name.

Northline. Thirty graded refund cases, including five traps (the out-of-warranty claim that should be refused; the duplicate-refund attempt; the goodwill case that needs a human). Re-run weekly and before every model or policy change. When a provider update quietly changed how the model read delivery-scan dates, the golden set caught it on Monday morning — score dropped, autonomy narrowed itself, the team adjusted, the set passed, full operation resumed. No customer ever saw it. That non-event is what Navigation buys.

The whole delta, on one desk

Worked honestly, BEACON produces six written pages — Candidacy decision, cost model, architecture record, boundary sheet, review-point map, evaluation plan. Together they are three things at once: the design your builders build to, the governance record that answers any auditor, risk committee, or regulator (the dimensions map directly onto frameworks like the EU AI Act, NIST AI RMF, and ISO 42001), and the operating basis for running the system after go-live. Six pages. Most AI projects have zero of them — which is why most AI projects surprise their sponsors.

Two rules for applying it. Candidacy first, always — an honest no at the start is the cheapest outcome in AI. And validate before go-live — each dimension checked against its written page, as a gate, not a meeting. A workflow with a blocking gap in any dimension is not ready, whatever the demo looked like.

If you are starting an agentic build this quarter, try this: take your current design document and check which of the six questions it answers in writing. For most teams the honest count is one or two. The gap is your design delta — and closing it costs days, while discovering it in production costs the project.

BEACON is the workflow design method we use at AI for Growth, and it pairs with the operating discipline we'll introduce in a follow-up article: how a well-designed system is kept well once it is live.

By Sai Krupa Sagar. To understand the complete BEACON framework — or to apply it to a critical system you are designing — reach us at aiforgrowth.io/contact.