{"slug": "the-unconference-asked-the-right-questions-here-s-one-architecture-s-answers", "title": "The Unconference Asked the Right Questions. Here's One Architecture's Answers.", "summary": "Thoughtworks' podcast episode on the future of software engineering highlighted open problems in agentic engineering, and a developer responded by detailing how their IRC-A architecture addresses these issues. The architecture enforces security and boundaries through infrastructure rather than prompts, using isolated tool servers and logical channels to prevent agents from accessing sensitive systems.", "body_md": "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](https://www.thoughtworks.com/en-gb/insights/podcasts/technology-podcasts/what-does-future-software-engineering-look-like)).\n\nIf 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\"*\n\nThe 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.\n\nFull 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.\n\nEarly 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?\n\nHis answer is the best line of the whole episode:\n\n\"No, you need to have infrastructure and systems that don't allow something running in your development environment to connect to your production database.\"\n\n** 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.\n\n**IRC-A** draws a hard network boundary instead: only the FastMCP tool servers, running in isolated sandboxes, hold database drivers and credentials.\n\nThe 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*.\n\nAndrew describes something anyone running agents on a real codebase has felt:\n\n\"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.\"\n\nHis 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.\n\nBut 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.\n\nAn 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.\n\nKief 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.\"\n\nI'd argue there's a level above scripts, and agent systems need it: cryptographic constraint.\n\nWhen 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.\n\nThe 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.\n\nA markdown file can be talked around. A script can be called with different arguments. A signature can't.\n\nKen 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.\n\n*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.\n\nBoth guests pushed back on giving agents \"**personalities**,\" and Kief landed on the framing I agree with:\n\n\"Think about those workflows and which parts do you want to hand off to an LLM to carry out... it's very task-oriented.\"\n\nIRC-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.\n\nThe \"theater of control\" thread was the most philosophically honest part of the episode.\n\nAndrew: \"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?\"\n\nMy 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.\n\n**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.\"\n\nThere 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.\n\nMost 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.\n\n**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.\n\nIn 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?\n\nHow 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.\n\nIt'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?\n\nIf you're working on that question too, I'd genuinely like to compare notes:\n\nAnd thanks to Ken, Kief, and Andrew for an episode that asked better questions than most keynotes answer.", "url": "https://wpnews.pro/news/the-unconference-asked-the-right-questions-here-s-one-architecture-s-answers", "canonical_source": "https://dev.to/sandrog/the-unconference-asked-the-right-questions-heres-one-architectures-answers-cc6", "published_at": "2026-07-31 07:12:52+00:00", "updated_at": "2026-07-31 07:38:02.535552+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-safety", "developer-tools"], "entities": ["Thoughtworks", "Ken Mugrage", "Kief Morris", "Andrew Harmel-Law", "Martin Fowler", "IRC-A", "FastMCP", "BFA Gateway"], "alternates": {"html": "https://wpnews.pro/news/the-unconference-asked-the-right-questions-here-s-one-architecture-s-answers", "markdown": "https://wpnews.pro/news/the-unconference-asked-the-right-questions-here-s-one-architecture-s-answers.md", "text": "https://wpnews.pro/news/the-unconference-asked-the-right-questions-here-s-one-architecture-s-answers.txt", "jsonld": "https://wpnews.pro/news/the-unconference-asked-the-right-questions-here-s-one-architecture-s-answers.jsonld"}}