How to Build a Governed Agent Stack

The guest is Mikhail, who heads the department behind the internal development platform at cloud.ru. They call it a PDP rather than an IDP — a product development platform, a wording that shifts the focus slightly; the platform partly aggregates the company's own services. Alexander notes that a cloud provider's products are engineering-shaped by nature, so their PDP differs little from a classic IDP. Mikhail then explains why building your own versus taking somebody else's is a false question: it is asked on two levels at once. For the company it is an ecosystem matter — the cost of a mistake, personal data, secrets, and a manager's personal liability for security rules built up over years. For a developer it is local: this tool solves my task and that one does not, and tomorrow Claude Code may be taken away. The answer, Mikhail argues, is not a side but a division of labour: simple summarisation or drafting letters need not go to the most expensive model.

Alexander breaks the stack into five parts. The harness runs the agent loop and supplies context; a model without a harness stays in request-response mode; tools give it hands, without which it is clever but helpless; identity, which Mikhail asked to name in the announcement, keeps people and agents apart; boundaries hold the agent inside the fence. Asking different experts earlier felt to Alexander like blind men touching an elephant: each part described, no picture. Every axis can be built or bought: write a harness, take an open one, or take Codex, which he thinks is open; take a closed provider model, open weights on your own hardware, or a regional provider's hosting; take MCP from a cloud CRM, or write adapters to an on-premise twenty-year-old monster. Hence the false dichotomies: open source is not local inference, a local model is not a safety guarantee, a carelessly built internal MCP opens everything to the agent, and an external API under a proper contract does not mean leakage.

A separate thread: why the harness matters more than the model. Mikhail explains that Claude Code sees only the repository: it knows neither your development rules, nor the wiring between microservices, nor the business constraints, and invents whatever is missing. An example from their work: once the agent sees the autotests it adapts to them, ask for eighty per cent coverage and it generates exactly that; move testing outside its view and run it afterwards, and the result improves. Alexander calls this overfitting to instructions. Betting on your own harness is risky too: abroad, he says, teams keep the platform thin and invent no harness, because a new model ships within months and the harness turns from accelerator into brake. Mikhail agrees that a harness written for optimisation loses its value with the next release. Complexity moves to the provider: on the day of the recording Alexander sent a task into deep research mode, a pack of subagents dug for two hours, a five-hour quota burned, and no report ever arrived.

The practical centre of gravity is a pair of gateways. The model gateway sits between harness and models and at its best routes by task type itself, like the automatic mode in Cursor; it also catches leaking secrets and personal data. The tool gateway owns the second path: which tools and MCP servers the agent may call, and whether it runs in a sandbox. For Mikhail it is already an engineering project: a standard forward proxy inspects all traffic and masks secrets and personal data. Digging into how Claude Code works, they found it reaches into ignored files and later recalls a password from an unclear source. Withholding data is impossible — processing loses its value — so it is masked and unmasked again, and everything comes down to speed. The filter is imperfect: they work with a pilot group, review traffic by hand and tune regexes, and by Mikhail's rough reckoning are near ninety-nine per cent, while LLM-based analysis is always slow, so they hunt for lightweight models that detect well. Alexander adds that designing such a gateway became an exercise in his forthcoming system design book.

Alexander walks the eight configurations from strictest to loosest. The first is an autonomous air-gapped stack with no internet: the whole perimeter is yours. The second keeps your own harness and corporate model gateway but calls a frontier model over an external API, so only one block is outsourced. The third puts a ready open-source client on top of a model you serve yourself, or a local one on a box at home, as Alexander sometimes does for agent prototypes. The fourth is a vendor coding agent such as Claude Code plus your own tool gateway exposing MCP into the internal platform; many companies abroad, he observes, take that route once a contract is signed. The fifth is full SaaS for a startup or a pet project. The sixth is a multi-model router whose classifier decides what stays local, what goes to a regional provider and what to an external frontier model. The seventh plans with a strong external model and executes with a cheaper one inside, so metadata rather than private data leaves the perimeter and the bill drops. The eighth is a personal stack with MCP servers for mail and a drive, which at scale, Mikhail admits, people use for work tasks — and that is hard to detect.

The closing minutes go to threat modelling. Mikhail points out that each threat model is its owner's own, starting from attack surface and data value: a single-page application ships its sources in bundles anyway, while for a unique algorithm carrying the whole product you may decide to work without agents at all; he recalls arguing with security about weak certificates on CDN machines that served public data. Alexander walks the red arrows of the diagram: an untrusted repository you ask the agent to analyse; secrets travelling between harness and model; an injection inside an email after which the agent forwards the mailbox outward instead of summarising it; permissions so broad that a tool sees not the Mikhail allowed to read one table for a dashboard, but Mikhail in full, able to drop that table. Mikhail replies that new MCP servers there first pass an allowlist and security approval, and Alexander adds the twelve boundaries from the longread: an operating system sandbox, denied outbound traffic, least privilege, on-behalf-of identity. Rolling them all out at once out of FOMO is a mistake, he argues, closing by inviting Mikhail back to take one subtopic deeper, perhaps the model gateway.