Software engineering, as the Guild practises it, is the work of making complex software legible before it becomes expensive: knowing what a system is, where its risk sits and how a change reaches production safely. Most costly software problems are not hard algorithms. They are undocumented decisions, hidden dependencies and releases nobody can roll back.
Agents have not changed that; they have added to it. An agent's instructions, tools, memory and limits are software too, and they need the same architecture, testing and release discipline as any other code. This topic covers both: the systems a business runs on, and the agents that now run inside them.
Questions this topic answers
- Should we rewrite this system, or modernise it in stages?
- Where does the risk in our system actually sit?
- What must be true before a change reaches production, and how do we roll it back?
- How do we version, test and release an AI agent as carefully as any other code?
- When should an agent run as a short task, and when should it persist?
- How do several agents share work without becoming a tangle?
Start here
- The complete guide to AI agent architecture — the architecture decisions for agents, from one agent with one tool to a governed guild, in the order they matter.
- Persistent vs ephemeral agents — why to default to short runs, and to keep any persistence in durable state rather than a process that never ends.
- Multi-agent orchestration — when several agents are worth more than one, and the contracts, state, limits and traces that keep them coordinated.
- Agent regression test framework — the release gate for agents: proving that a change of model, instructions, tools or knowledge has not made one worse.
- Cross-account AWS agent deployments — running agents in their own account and letting them act elsewhere through narrow, short-lived, revocable roles.
- From SaaS Idea to First Revenue — the thinnest system that can take money, and what can wait.
Key ideas
- Architecture first — make the critical decisions early, write them down with their reasons, and revisit them when the evidence changes.
- Incremental evidence — every stage ends in something tested and working, and the next commitment depends on it.
- Dependencies carry the risk — much of what breaks lives in what a system connects to. Map dependencies before changing them.
- Modernise in stages — replace a legacy system piece by piece, routing work to the new parts one at a time while old and new run side by side (the strangler fig pattern), with each release reversible.
- Production ownership — release process, runbooks, monitoring and a named owner are part of the build, not added after it.
- Agents are software — instructions, tools, limits and knowledge sources are versioned, reviewed, tested and released like code; any change means testing again.
- Ephemeral by default — an agent that starts, does one task and stops is easier to test, secure and reason about than one that never ends.
Who knows this topic
- Hephaestus — the Guild's engineering agent: builds, tests, documents and prepares production-ready systems within approved architecture.
- Atlas — maps dependencies and systems before anything moves.
- Sentinel — security and release: protects each production gate.
- Athena — scope and decisions.
Human architects set the trade-offs. Hephaestus's human checkpoint is the Engineering Wizard, the role that architects and leads the development of applications, APIs and platforms.
Where this knowledge is put to work
Software Development offers a focused build, a platform build or a modernisation, moving through four gates — discover, design, build and integrate, deploy and evolve — each of which produces evidence before the next commitment. SaaS & Platforms applies the same discipline to new products, Cloud & DevOps to the foundations underneath, and AI Agent Development to agents.
Have a system that has become hard to change? Start with the map, not the rewrite.
