Blog · Applied AI
We Don't Build One Big Agent
Task-specific beats one-size-fits-all, and the reasons are structural.
By Michael L. Atkinson · August 8, 2026 · 3 min read
Every few weeks someone asks us to build an AI agent for the business. Singular. One system, pointed at everything, answering whatever gets asked. We don't build that, and not because it is difficult. It is the wrong shape.
Consider what we have actually built inside our own portfolio. FohBoh Sentry recovers money restaurants are owed, and it does that through modules that barely resemble one another: one reconciles delivery-service settlements against point-of-sale orders, a second reconciles merchant processor statements against deposits, a third tests franchise royalty calculations against the disclosure document. The delivery module carries eighty-three rules and the merchant module carries a hundred and seven, and they overlap almost nowhere, because an aggregator's fee schedule and an interchange table have nothing in common except that both are used to take money out of an operator's account. FohBoh Cortex is narrow in a different direction entirely — it answers operational questions in voice and text but reconciles nothing, reading only what the Metrics Governance Engine has already certified. StarBar's SnapCount does one thing that sounds trivial until you have watched somebody do it with a clipboard: it walks a bartender through a twelve-item watchlist one bottle at a time, takes the count by voice, and refuses to certify it unless six conditions all hold — a named opening count, a named closing count, both inside the shift window, variance under threshold, a trust score at or above the floor, and no unresolved exception. Five of six is not a certified count. That rule is the entire product, and it only works because the scope is one shift, one watchlist, one manager who is accountable by name. BailiwickQuikFix runs field applications over a licensed governance engine for a different operating problem again. None of these could be merged into a single agent without making every one of them worse.
The reasons are structural rather than stylistic. A narrow agent can be tested, because when the job is finding fee variances in a settlement file you can write down what correct means and then check it, whereas helping with the business cannot be scored and so you never find out that it is wrong. A narrow agent also fails visibly, which matters more than anything else here: a general-purpose system producing a bad answer sounds exactly like one producing a good answer, while a scoped agent has a defined output with defined bounds, and a violation looks like a violation. Constraints are cheaper to encode when the job is small — a hundred rules about merchant fees is a tractable body of knowledge, while a hundred rules covering everything a restaurant company does is a rewrite of the company. And a narrow scope gives domain expertise somewhere to land.
That last point carries more weight than it usually gets, because two kinds of standards govern any agent and both are routinely underestimated. Brand standards decide what an agent is permitted to say — voice, register, the claims it must never make, the questions it must escalate rather than answer — and an agent talking to your franchisees is speaking as you. Business standards decide what it is permitted to conclude: which formula is authoritative, which denominator is approved, which source of record wins a disagreement, what variance threshold requires a human being. Those are the same questions a governance engine asks, they have real answers inside every company, and the answers are usually undocumented and held by three people.
Both kinds of standards change. Fee structures move quarterly, brand positions move with leadership, and thresholds tighten as an operator learns what its own numbers actually look like. So we build them as reviewed configuration on a cadence rather than as prose buried in a prompt where nobody can audit it. An agent is not finished at handover; it is instrumented at handover.
None of this works without somebody on the build who already knows that a promotional adjustment and a chargeback are different things, that a comp is not a discount, and that food cost percentage means three different numbers depending on who is asking. Without that you get an agent that is fluent, fast and confidently wrong, which costs more than having built nothing at all.
And underneath all of it, in every case: the trust layer first, then the agent. In that order, permanently.
Keep reading.
More on trust, architecture, and the systems that decide whether a company can rely on its own numbers.