What changes about architecture when the primary consumer of your repository is a machine with no institutional memory.
Every architecture decision you have ever made assumed a reader who accumulates context. A new engineer joins, is confused for a fortnight, absorbs the unwritten rules from code review and lunch, and by month three knows that you never touch the billing module on a Friday and that the legacy_ prefix means "load bearing, do not delete".
None of that transfers to an agent. Every session starts from nothing. It reads what is written down, and it can be confidently wrong about everything else. A solid architectural foundation used to be an accelerant. In the agentic era it is a precondition. Human duct tape can hold a poor architecture together for a human team; it will not buy your agents autonomy. The tolerance for a bad foundation has gone to zero, and the same tools that raised the bar will help you reach it.
Part 1 set the scene. This part covers what changes in the tech stack to enable agentic orchestration.
What is a good foundation?
A good foundation spans the four signals: people, process, architecture and measurement. Five questions to litmus test your organization:
One. How quickly can a new team member spin up their development environment?
I love this question because it tells you so much about an organization and its architectural history. The utopian goal: an engineer runs one command and their environment is running locally, every dependent service set up, the app ready to go.
Two. Is your application's configuration independent of the code?
Config never belongs in code. If your codebase contains references to production, staging, QA or dev, that is a red flag. Anything that varies between deploys lives outside the source.
Three. How extensive is your use of ClickOps?
ClickOps: a human clicking through a console to produce an artifact the team depends on. If that is part of your day-to-day, it is a ceiling on automation.
Four. Where is your business logic recorded?
I have written about this before. If your business logic is not codified in code, tests, wikis or BDD-style specifications, it is a problem at every stage of feature development.
Five. How are you measuring your team's performance?
Gut feel, tooling, reporting, 1-1s. What is the actual process?
Questions one to three test whether agents can create and destroy repeatable environments for development, testing and research. Four determines whether an agent can verify old and new behaviour at all. Five tells you where you are and whether you are improving. A full treatment of foundations is a book; these five set the scene.
Context shifts to the repo
Everything the agent needs lives in the repo. Work items, review evidence, agent configuration, architectural decisions, and the code that satisfies them all version together in one history. Not a wiki. Not a ticket tracker. Not a decision log in a separate tool that nobody updates. One history. The practical test is simple: check out a commit from six weeks ago. Do you get the tickets that were open, the requirements that were agreed, and the decisions that were current? Or do you don the paleontological brush and sift issues, PRDs, wiki pages and Slack threads to unearth the T-Rex of original requirements?
Issue tracking
Traditional issue trackers are too slow for agentic work; the work-item layer belongs in git. In Gas City this is Beads: a git-backed, dependency-aware issue tracker that is versioned, committed, works across teams and repos, and gives tasks the durability that sessions lack. Sessions restart, work items persist; the agent picks up tomorrow exactly where the graph says it left off. Underneath, Dolt provides a version-controlled database, so every state change an agent makes is also a commit. Products like Jira will likely morph into human-facing feedback loops outside the code-creation path.
Documentation
Feature planning and outcome records follow the same logic into the repo, where agents have the context to make good decisions autonomously. I split documentation into two folders. plans/ holds transient artifacts that move through backlog, active and done, with anything older than 30 days archived. docs/ is permanent: the recorded facts about the repo. A folder-organization skill runs periodically to keep the structure honest, and whenever a feature completes, the workflow reviews docs/ and updates the key records. The folder picture below shows the sub-folders used.
ADRs become essential. The expensive knowledge in any codebase was never what you built. It was what you deliberately did not build, and why. That knowledge used to live in senior engineers' heads and leak out when they left. It is now the difference between an agent that helps and an agent that quietly undoes six weeks of decisions.
Structured business logic
I have argued before that undocumented business logic is a red flag; it is why it makes the litmus test above. An agent will not organize a Slack huddle with your two bottleneck engineers to find out how the product should work. Plenty of organizations run on exactly that practice, interrupting flow and destroying deep-work time in the process. Having written that, I now expect to see the product version: an AI bot that interviews team members and emits BDD specifications. Did I just invent a product?
Documented business logic pays out across the whole life of a product:
- Planning: clarifies intent.
- Implementation: input for automated testing, and therefore reliability.
- Go-to-market: input for the knowledge base and automated help agents.
- Maintenance: refactoring is easier, safer and more enjoyable because tests back your changes.
- Output: fewer meetings to discover how things should work, more deep-think time.
With agents in the loop this stops being a philosophical position and becomes an operational one. Without business logic captured in BDD or automated tests, your feature loop has no guardrails for repeatability. Gas City Formula workflows let you map the life of an epic structurally, through planning, implementation and review, but the quality gates only bite if there is documented behaviour to gate against. On a brownfield product with a weak foundation there is honest work to do here first.
Write the logic down, so an agent can read it. Test it, so an agent cannot break it silently. Review against it, so an agent cannot ship something that technically passes but violates the intent. If your invariants live only in the heads of two people, you do not have a documentation problem. You have a system whose verification layer is a human bottleneck, and a factory will hit that bottleneck at a rate you are not prepared for.
Agentic artifacts
Skills, prompts, MCP servers, agent definitions, workflow templates: the configuration surface of an agentic team grows fast, and every provider expects it in a different place, in a different format. Maintain those artifacts by hand in every repo and you are back to copy-paste configuration drift, the same disease configuration management spent a decade curing.
Gas City's answer is packs: composable directories of agents, skills, formulas and prompts that you install, fork and version like any other dependency. The repo does not carry a skills directory at all. The harness materialises the right artifacts in the right locations for whichever provider it is starting, so the same pack drives Claude, Antigravity or Kimi without per-provider forks. Write a skill once, version it once, and every rig that imports the pack picks up the change. It is DRY applied to engineering judgment.
Developer experience
As you manage more agentic harnesses context switching can be dizzying. A consistent developer experience is what keeps that survivable, and it has a second beneficiary: agents spin up environments through exactly the same commands humans do. No separate agent path to maintain, no drift between the two.
I make heavy use of mise: "Your dev environment, prepped and ready. One tool that manages dev tools, env vars, and tasks per project." it's good to be independent of cloud and model providers to maintain your flexibility. in each repo I know that mise setup local sets up my local dev environment. I don't have to hunt around for the right commands. It generates the environment file from a tracked template, starts Postgres and a local mail catcher, applies migrations, and brings up both the frontend and the extraction pipeline. No cloud dependency, no API key required, because the pipeline defaults to replaying checked-in fixtures. Deterministic and offline. The same mise tasks run in CI/CD, so "works locally" and "works in the pipeline" are the same claim, and mise pins the toolchain versions so every human and every agent runs the identical stack. An agent that can run the full stack locally is more deterministic and successful. Developer experience is not a perk here; it is the substrate the whole factory sits on, with good DevOps playing an essential role in modern agentic teams.
No config in code - ever with a generated configuration created from the mise setup local command. Local devs can get going immediately. No environment names in code, no hand-maintained config: litmus question two, enforced by tooling rather than review comments.
Enabling twelve agents to work at once
Parallelism is the point of a factory and it is also a potential new failure mode. Twelve agents editing one working tree is a corruption problem. Isolation is the answer and it has to exist at three levels. Each agent session gets its own git worktree, so concurrent work cannot collide on disk. Each feature branch gets its own preview deployment automatically. Infrastructure is provisioned per environment from code, using good Infrastructure as Code practices.
Coupling matters more than it used to for the same reason. A tightly coupled module is one where a scoped task cannot actually be scoped, so the agent widens its blast radius to get the job done, and your small change touches nine files. The traditional argument for low coupling was human comprehension. The new argument is that coupling determines whether work can be decomposed into a graph at all, and if it cannot, you do not have a factory. You have twelve agents queueing.
CI/CD
CI/CD is another gate for consistency and reliability. When an agent believes it has finished, it runs the automated checks, locally or remotely, and responds to the output. Five tiers: lint, typecheck, build and unit tests, then integration, then E2E, then a preview deploy. Deploys are blocked unless everything is green. Pre-commit hooks stop agents and humans alike from committing code that fails linting, type checks, formatting or unit tests. A pre-push hook refuses pushes to main when CI is red. A scheduled job records the gate result for main daily, so a multi-day red streak is visible rather than discovered.
The design principle: the gate must be cheap, automatic, and non-negotiable. Cheap, because a factory will hit it hundreds of times a week. Automatic, because a check that requires a human is a queue. Non-negotiable, because the moment a gate becomes advisory it stops shaping behaviour, and agents are exquisitely good at finding the path of least resistance through a system that has one. That is the real reason software industrialized before other knowledge work. Not because code is easy. Because code has cheap, automatable checks, and most disciplines do not.
Greenfield v brownfield
Greenfield is easy, brownfield is hard, goes the convention. I got to choose the stack, write the conventions first, and never fight a decision made in 2014. A factory pointed at a decade-old codebase with implicit business logic, no test coverage, and three ways to do everything is a substantially harder problem, and it is the one most engineering organizations actually have. I have not solved it, and eight weeks of greenfield will not tell you much about it. The principles transfer, though, because brownfield is only hard in proportion to the foundation underneath it.
If you cannot leap into agentic orchestration, then review, measure and plan the foundation work first, and put AI on that job too: the same agents that need the foundation are effective at building it. Every one of those improvements is something you would have wanted anyway. The difference is that the return on them just went up by an order of magnitude, and the excuse for deferring them went away. Competitors that adopt these principles have collapsed the distance from idea to implementation to near zero. The time-to-market moat you were relying on has evaporated.
A deliberately dull stack
The stack is deliberately dull and deliberately narrow. One router. One ORM that owns the entire schema, including the auth tables. One formatter. One package manager. TypeScript in strict mode. The README calls it a locked stack and means it.
Variance was always a tax. In a human team it costs onboarding time and review friction, and a good engineer absorbs it. In an agentic team it costs correctness, because every additional way to do something is another branch in the space of plausible outputs, and the agent has no taste to tell it which one this codebase prefers. It has a pattern-matcher and whatever it can see.
Summary
There are more changes than one article can cover; these are the ones with the highest return. The usual challenges remain: your product will still have bugs, rough edges, and a backlog. What changes is the cost of clearing them, and that cost depends on the quality of your foundation and your agentic setup. Write it down, gate it, generate it, and keep the variance low.
Writing code is no longer the constraint. If your engineers spend more than 10% of their time typing code, you have foundational or agentic work to do. Part 3 goes inside the factory itself: the feature loop from work item to reviewed pull request.
Part 1, Building Production Grade Applications using Agent Orchestration. After eight weeks I built a production grade application. Five weeks spent building and learning the factory, three building the product. Pre-AI this product would have taken at least six months and a team of 3-5 to build. link
Part 2, Architecture. What changes about system design when the primary reader of your codebase is a machine with no institutional memory, and twelve of them are working at once. What are essential foundational elements needed to be autonomous? link
Part 3, Process. The nine-step build workflow, the two human gates, and the thirteen artifacts one feature leaves behind. coming soon
Part 4, People. What is the human's role in this process. How has it changed? What grows, what shrinks, where do we sit? What are the new teams and structure needed to take full advantage? coming soon
Part 5, Measure. How do we measure in this new era? What were the stats of this project? What survives from DORA, and a metrics set for an org where machines write most of the diff. coming soon
This is a portfolio product and a portfolio article. If you want help getting your engineering team or organization onto this footing, from a lunch and learn through to a one to twelve month advisory engagement, fractional CTO work, or engineering leadership for your team, get in touch.