I just finished the Thoughtworks Technology Podcast episode where Ken Mugrage, Kief Morris, and Andrew Harmel-Law debrief the unconference on the future of software engineering they ran in Switzerland with Martin Fowler (full transcript here).
If you haven't listened: the mood has shifted. A few months ago these conversations were "look at the shiny stuff." Now it's "We know this can work, but we need to answer these questions" The episode is basically a tour of open problems in agentic engineering — trust, boundaries, control, governance — and what struck me is how many of them are infrastructure problems wearing a prompt problem's clothes.
Full disclosure before we start: I've spent the last months building IRC-A (Internet Relay Chat for Agents), a decentralized architecture pattern and SDK for multi-agent systems. So when I say ** "here's how I'd answer that,"** I have a specific, opinionated architecture in mind — take it as one practitioner's answers, not gospel. Now, the questions.
Early in the episode, Kief brings up a fear someone raised: what if the agent, left unsupervised, connects the development environment to the production database to grab some data?
His answer is the best line of the whole episode:
"No, you need to have infrastructure and systems that don't allow something running in your development environment to connect to your production database."
** Exactly**. And this is where I'd push further: in most agent architectures today, the conversational agent holds the database credentials. We then spend enormous effort on prompt engineering and code review to stop it from misusing them. That's controlling behavior through hope.
IRC-A draws a hard network boundary instead: only the FastMCP tool servers, running in isolated sandboxes, hold database drivers and credentials.
The reasoning agents physically cannot connect to anything transactional — they don't have the drivers, the credentials, or the network path. A prompt injection telling the agent to drop schema corporate_financials fails not because the agent refused, but because there's literally nothing in its environment that could execute it. Security you don't have to remember to enforce.
Andrew describes something anyone running agents on a real codebase has felt:
"Agents can roam around... they're very sycophantic, they want to do what you've asked them to do and make you happy. If you want them to do that while still... protecting some boundaries in a codebase, they highly possibly will not respect that. Even if you start with something clear, the edges can get blurred very fast."
His observation that teams are going back to microservices in separate repos "because this agent can't change this — it has no rights to change this codebase in this repo" is telling: we're rediscovering that boundaries only work when they're enforced by the environment, not described in instructions.
But splitting repos is a blunt instrument. IRC-A enforces the same property with logical channels: every node (agent or tool server) declares its channels via environment variables (IRCA_CHANNELS="#aml-restricted,#compliance-audit"), and the BFA Gateway masks capability discovery inside the FAISS index accordingly.
An agent on #finance can't even see that an AML tool exists — the capability is filtered out of the vector search before matching. The boundary lives in the infrastructure, where sycophancy can't talk its way past it.
Kief outlines a hierarchy of assurance: markdown skill files and AGENTS.md give you some guidance, but "scriptable tools that are executed and do particular tasks in a predictable way" are stronger. He calls them "levels of strength of assurance."
I'd argue there's a level above scripts, and agent systems need it: cryptographic constraint.
When an IRC-A agent wants to invoke a capability, the BFA Gateway mints an Ephemeral Delegated Execution Token (DET) — a PASETO token signed with Ed25519, scoped to one function, with parameter lockdown.
The tool server verifies it offline against the Gateway's public key and checks that the runtime arguments match the locked parameters exactly. fetch_customer_credit_score(customer_id="882") runs; the same function with "885" is rejected at the door.
A markdown file can be talked around. A script can be called with different arguments. A signature can't.
Ken asks the organizational question — who owns the harness, the platform team? — and Andrew points at platforms that "bless" certain harnesses and skills so teams get non-functional requirements (compliance, data handling, replication) along with functionality, especially in regulated environments.
That maps directly onto IRC-A's separation: the BFA (Backend for Agents) is strictly a governance perimeter — registry, capability directory, cryptographic minting. It never runs reasoning loops and never touches transactional data. The platform team owns governance; product teams own execution. Governance as its own layer, or — as I've said before — it gets entangled with execution and both rot together.
Both guests pushed back on giving agents "personalities," and Kief landed on the framing I agree with:
"Think about those workflows and which parts do you want to hand off to an LLM to carry out... it's very task-oriented."
IRC-A takes this to its conclusion: cognitive agents are stateless specialists with exactly one responsibility. An agent shouldn't know the ecosystem it runs in — only its own objective. No BA agent persona, no 73-agent org chart with an optimist and a cynic. Capabilities, not characters.
The "theater of control" thread was the most philosophically honest part of the episode.
Andrew: "We've always had a lot less control than we thought we did." Kief questioning whether pull requests ever guaranteed catching human mistakes, "or is that just theater?" My take: they're right that reviewing every line was always partial. But the conclusion isn't "give up on control" — it's move control to where it's deterministic.
IRC-A can't guarantee what an agent reasons, and doesn't try. It guarantees what an agent can execute: every inter-agent request carries a trace_id and a visited_nodes list, so circular delegation loops are detected and rejected by the SDK itself. Every execution requires a valid, scoped, unexpired DET. The reasoning is free; the boundary is not negotiable. Predictable where it matters — which is exactly the word Andrew suggests we use instead of "determinism."
There was a session on building an organizational knowledge graph so agents can "draw the right information that it needs without having to fill its context with everything." Yes — and this problem is bigger than knowledge.
Most multi-agent frameworks fill the context with everything: every tool schema, every API contract, the entire conversation history, on every single call. That's prompt-bloat, and it's why token costs scale so badly.
IRC-A attacks it from two sides. Semantic capability discovery: agents don't carry tool schemas in their prompts — they describe intent in natural language, and the Gateway's FAISS index matches it to a registered capability at runtime. And prompt rewriting at the delegation boundary: before delegating to a specialist node, the entry agent strips the conversational history and system instructions down to a minimal structured execution prompt. "Open a bank account for client John Doe, SSN 123-12-1323" — that's what travels, not the whole chat. The result, measured in LangSmith over complete roundtrips, is a practically fixed token cost per call regardless of session length. In my benchmarks against a traditional orchestrated setup, that difference came out to 18x.
In the spirit of the unconference's honesty: the hardest questions in that episode aren't architectural. Where does the developer sit now? What survives of TDD?
How do we articulate to the LLMs why maintainability matters — the things Kief said we always struggled to articulate to management? IRC-A doesn't touch those.
It's an answer to a narrower question: what should the infrastructure under agentic systems look like if we take 30 years of software architecture seriously?
If you're working on that question too, I'd genuinely like to compare notes: And thanks to Ken, Kief, and Andrew for an episode that asked better questions than most keynotes answer.