The Operator Is the Buyer

By now I have described the takeout architecture, six layers between an agent and the data it acts on. What it skipped however is the question of who configures any of it, and almost every product in this market just so happens to be making the same mistake about that question.

Meet Tanaka. IT administrator at a mid sized regional bank, twelve years there, started in desktop support, moved up to systems administration, now runs a small team doing endpoint management, identity, rollouts of new internal tools. She has a CISSP. She is competent. She is not a security researcher, and she does not write YAML at 2am unless she absolutely has to.

Tanaka is the person who decides in practice whether the bank’s agent deployment is safe. The model vendor does not decide that, and neither does platform engineering or the executives who signed the contract, she does. She will do it by writing policies, granting permissions, configuring scopes, approving rollouts, watching dashboards for stuff that looks wrong. If she misconfigures something the bank is exposed, if she over configures the agents get so locked down the business side complains to her boss. She has to find that line and hold it every single day, against threats that keep changing and a constant stream of new business asks. I have worked with many Tanakas over the years, they are the ones actually holding these systems together.

And what does the market hand her? Mostly a YAML file, or a JSON schema, or a policy as code framework in a syntax invented by someone who thinks like an engineer, or a control plane dashboard that demos great and assumes she already understands the primitives well enough to author them.

Tanaka is the customer, and nothing in this market is designed for her.

The console she actually needs looks like this. She opens it in the morning and three things sit at the top, people, capabilities, policies.

People is the easy part, an org chart synced from HR. Everyone has a role, sales rep, account manager, branch manager, internal auditor, and roles are not just labels, the system uses them to decide what is allowed.

Capabilities is the catalog of declared scoped operations. Not access Gmail, that is the broken model. Read emails the user marked work relevant, from the last 90 days, summaries only. Query the CRM for accounts the acting user owns. Draft a reply into the acting user’s review queue, never straight to a recipient. Initiate a payment up to $50,000 with the acting user’s hardware key confirmation. The catalog grows to hundreds of capabilities and eventually thousands, some from the platform vendor’s baseline, some from industry bodies like a financial services consortium, some built by the bank’s own engineering, and every one carries a declared scope, a declared output and a risk classification.

Policies are the rules about which roles get which capabilities under which conditions, and Tanaka writes them in a structured editor, dropdowns, conditions, role pickers. She does not write code for it. She picks Finance from a dropdown, picks Initiate Payment from another, sets the threshold with a slider, checks two party approval.

She can simulate, show me everything an account manager’s agent could do under this policy set if their principal authorized it, and the console lists it out and she previews and adjusts. She gets warned on the sensitive stuff, this policy allows payments up to $1M without two party approval, the industry standard for this role is $50K, are you sure? It is not punitive, more like a coach who has seen how similar policies failed at other places. The console shows her what the agents are actually doing, and not as a firehose of logs but as anomalies, orders that don’t match historical patterns, capabilities used at weird hours, an agent that suddenly started doing things it never did before, and every anomaly is one click from its full receipt chain.

When something is wrong she can act at whatever level fits, pause one capability for one role, revoke an agent’s authorization, force re authentication, lock a session, or roll back the policy change she made an hour ago that caused the spike of weird activity. And when something is really wrong she has the receipts, complete by construction. She does not reconstruct events from log fragments, she hands the chain to legal or the regulator with the answer already in it.

That is the console Tanaka needs, and almost nobody is building it.

I want to be careful here because a lot of serious agent infrastructure does exist. MCP gateways from Kong, Proofpoint, Cequence, MintMCP, Natoma, Obot, IBM, AWS and a dozen more. Trusted runtimes from EQTY Lab, Opaque, Phala, Atoma. Sandboxes from Northflank, E2B, Modal, plus the open source Agent Sandbox controller for Kubernetes, and Omega on the academic side. These are real products and many of them implement most of the takeout architecture, the chef exists, the cashier exists, the receipt log exists.

What is missing is the Tanaka console, the authoring layer that turns all of it into something a CISSP holding non developer can configure correctly. The pitches target platform engineers, the docs are written for them, the pricing is built around them.

Platform engineers are great customers, don’t get me wrong. But the purchasing decisions for high stakes agent deployment get made by CISOs and CIOs and chief risk officers, and every one of them delegates the actual configuration down to someone who looks like Tanaka. If she cannot make the system work it does not get deployed, or worse it gets deployed misconfigured and the first big incident sets the whole industry back years.

We have seen this exact movie before, with cloud. Early IaaS gave you raw primitives, IAM policies, security groups, encryption at rest, and configuring them right took a security engineer, so we got years of high profile breaches at companies that bought the right technology and set it up wrong. The industry’s answer was a wave of products making configuration legible to less technical buyers, cloud security posture management, SaaS posture management, identity threat detection. The market built the operator layer because the developer layer was not enough.

Agent infrastructure will follow the same curve. The current generation is the IaaS era equivalent, technically correct and operator illegible, and the generation that unlocks regulated adoption is the one that puts Tanaka first.

That is also where the buyer comes from. The CISO and the chief risk officer, they are the ones who lose their jobs when the agent fleet puts the company on the front page, so they are the ones who need cryptographic guarantees instead of vendor promises, and they will pay for the Tanaka console. The CIO buying productivity tools will not, and neither will the Head of AI buying models.

In the next essay I will take the architecture apart, where does it break, what can it not defend against? Honestly I trust an idea more once I know where it breaks.