“Are coding agents missing an architecture layer? I built an open-source agent harness to experiment with it”

I've been experimenting with a question that I think becomes more important as coding agents take on larger and longer-running tasks: Should software architecture become an explicit part of an agent's control loop? Most coding agents today roughly follow a loop like: Task → Explore repo → Reason → Edit code → Run tools/tests → Iterate This works surprisingly well, but as tasks become larger, I've been wondering whether we're asking the agent to reconstruct too much architectural intent from the codebase every time. So I've been experimenting with a different approach: Requirements → Architecture → Agent → Code → Tests → Repair The idea isn't to use UML as documentation. Instead, I'm exploring whether architecture can act as a structured intermediate representation between human intent and implementation — something the agent can inspect, reason about, validate against, and propose changes to. For example, a component diagram could describe system boundaries and dependencies, class diagrams could represent structural constraints, and sequence diagrams could capture important interactions. The coding agent would still inspect and modify the real codebase, but it would have another representation of what the system is supposed to look like. I've implemented a working prototype around this idea. The agent itself currently uses a ReAct-style loop and can inspect/edit files, execute commands, run real tests, repair failures, maintain task plans, and submit architecture changes for human review. I've also been experimenting with a few related ideas: Bounded sub-agents — sub-agents explore the project and return structured evidence, but the main agent remains responsible for modifications and verification. Cross-session memory — useful information from previous tasks can be retrieved into future agent runs. Architecture + code knowledge graph — connecting design entities, code entities, relationships, and test coverage. Full execution traces and replay — recording LLM interactions and tool calls so agent behavior can be inspected and reproduced. Agent evaluation — running the production agent against controlled project fixtures with hard checkers for tests, code structure, architecture validity, file integrity, token usage, tool calls, and execution time. The evaluation part has actually made me question the architecture idea even more. Architecture gives the agent additional structured context, but it also introduces another representation that has to remain synchronized with reality. So there seems to be a fundamental tradeoff: Architecture can reduce ambiguity, but architecture drift can create a second source of truth. Maybe the better direction isn't architecture at all. Maybe sufficiently good repository search, code intelligence, context retrieval, and memory allow agents to reconstruct architecture whenever they need it. Or perhaps the architecture representation should be generated dynamically from the code instead of maintained independently. I'm curious how people building agents think about this. For long-horizon coding agents, would you want an explicit architecture representation between requirements and code? Or should the codebase remain the only source of truth, with the agent deriving architectural understanding on demand? I'm especially interested in experiences from people working on coding agents, agent harnesses, context engineering, memory, planning, or multi-agent systems. I've open-sourced the prototype I'm using for these experiments. I'll put it in the comments for anyone who wants to look at the implementation or experiment with it.