Not Automation. Concentration: How Agent Systems Transform the Solution Architect’s Workflow
Two editions of this newsletter have laid the groundwork for a conversation that has not yet been named directly.
Edition 12 argued that going AI-first requires more than deploying a tool into an existing process. It requires understanding the process, redrawing it around AI, and being honest about which human steps survive that redraw and which do not. Edition 14 gave that argument an architectural foundation. The business process as the unit of analysis. The actor role as the anchor. The corpus of data as an architectural decision in its own right. The system contract derived from the actor’s specific needs. Auditability as a first-class requirement, not a governance afterthought.
This edition makes those arguments specific to the architect’s own work.
The solution architect’s workflow, from requirements intake to governance artefact, is a business process. It has inputs, outputs, decision points, and a specific actor whose judgment is the irreplaceable ingredient. It has a corpus of data it depends on. It has governance obligations that define what the output must contain and who is accountable for it. Every condition that Edition 14 named as a prerequisite for AI-first process transformation applies to the architecture workflow itself.
The question this edition asks is what agentifying that workflow actually looks like. Not in the abstract. In the specific: what agents, doing what work, against what data, governed by what contract, with the architect occupying what position in the system.
The image that best describes that position is the pilot in the cockpit.
The architect does not step back from the work when the agent system is running. The architect steps into a different relationship with it. The agents handle the analysis, the mapping, the pattern matching, the first-pass estimation, the draft artefacts. The architect directs, validates, decides, and owns. The grunt work that currently consumes the majority of an architect’s week, the work that prevents the judgment from being applied at the depth the role requires, moves to the agents. The judgment stays with the architect. So does the accountability.
What changes is not the architect’s responsibility. What changes is the proportion of the architect’s time available for the work that only the architect can do, and the depth of value that work can now generate.
The Workflow and the Agent System
The solution architect’s workflow has five distinct stages. Each one has a different relationship with AI. Understanding that relationship precisely is what the cockpit design depends on.
Requirements coherence analysis.
The architect receives requirements. They are rarely ready for design work when they arrive. They are partial, inconsistently articulated, and often carry assumed solutions where outcome statements should be. The architect’s first job is not to design. It is to assess whether the requirements are mature enough for design to start.
This is where the first specialised agent enters the conversation. As the architect reads through the requirements, the agent is reading alongside. It surfaces gaps against the pattern of what is present. It flags internal inconsistencies as the architect encounters them rather than after the architect has finished. It maps stated requirements to stated outcomes in real time and raises the ones where the mapping is absent or unclear. The architect and the agent are working through the requirements set together, the agent accelerating the identification of what needs attention, the architect directing where to probe deeper and making the call on what matters.
The coherence conversations with business stakeholders and product owners remain the architect’s work. The agent cannot have those conversations. But when the architect goes into them, they are going in with a structured picture of exactly where the gaps are and what questions need answering, built in a fraction of the time it would have taken without the agent working alongside. The decision on whether the requirements are mature enough for the next stage to begin is the architect’s. The agent has made the information on which that decision rests considerably sharper.
Discovery and gap analysis.
With coherent requirements established, the architect moves into mapping them against the existing estate. Business processes, functional capabilities, customer journeys, the application landscape. Three categories need to be identified: what can be reused, what needs to be incremented, and what needs to be built new.
The discovery agent is not running a separate analysis and presenting the results. It is working through the estate with the architect. As the architect interrogates a capability area, the agent surfaces what the catalogue says about it, what programmes have previously touched it, what the current technical status is. The architect pushes into an area of interest and the agent responds, pulling the relevant context from the corpus in real time. The architect challenges an assumption and the agent surfaces the evidence for and against it immediately.
What the agent cannot bring is what lives outside the corpus. The architect knows the application that looks healthy on paper is held together by institutional knowledge that is about to walk out the door. The architect knows the capability that has been flagged as a reuse candidate has failed delivery twice in similar contexts. That contextual knowledge is what the architect contributes to the gap map in conversation with the agent. The agent provides the structured picture. The architect makes it accurate.
Sizing and estimation.
The architect is asked to size the effort. The fidelity of that sizing varies depending on how much information is available. Plus or minus one hundred percent at early concept stage. Plus or minus thirty at requirements stage. Plus or minus ten when the design is mature.
The sizing agent works with the architect to build the estimate rather than producing one for the architect to accept or reject. The architect describes the scope and the nature of the work. The agent surfaces comparable previous programmes from the historical data and shows what they cost and why. The architect interrogates the comparisons, identifies where the current programme diverges from the historical pattern, and the agent recalibrates as the architect’s inputs narrow the picture. The estimate that emerges from that conversation is more grounded than one produced by either alone. The architect’s situational judgment is anchored by calibrated historical data. The historical data is adjusted by the architect’s reading of the specific conditions in front of them.
Solution design.
The actual design work. Technical capabilities identified, systems mapped, APIs defined, new capabilities specified. Build versus buy decisions, platform choices, domain boundary calls. This is where the architect’s choices will constrain the programme for years.
The solution design agent is the architect’s thinking partner through this stage. As the architect works through an option, the agent is checking it against the technology standards and the architecture principles in real time. It surfaces precedents from the decision record as they become relevant. It flags conflicts with existing standards as the architect encounters them rather than after the design is complete. When the architect is weighing a platform choice, the agent brings the relevant prior decisions, the constraints each option carries, and the dependencies each creates. The architect thinks out loud and the agent responds with the structured analysis that sharpens the thinking.
Alongside the architecture standards, the solution design agent holds the codified guardrails of every control function the architect has to satisfy. Data governance requirements. Security standards. Compliance obligations. Fraud controls. Operational risk thresholds. Currently, validating the design against each of those functions is a separate manual engagement, conducted sequentially, often after the design is already formed. Conflicts surface late. Rework follows. The architect manages each conversation individually and carries the reconciliation work between them.
With the guardrails codified and held by the agent, that validation runs continuously and in parallel as the design develops. The architect proposes a data flow and the agent surfaces the data governance implication immediately. The architect sketches an integration pattern and the agent flags the security standard it conflicts with in the moment. Where a guardrail can be met within the current design, the agent confirms it. Where it cannot, the agent isolates the specific gap and frames it as a precise item for conversation with the relevant control function. The architect goes into the data team conversation knowing exactly what the issue is and what resolution options the design can accommodate. The conversation becomes targeted rather than exploratory.
The result is a design that has been validated against all relevant guardrails as it was built rather than after it was finished. The conversations with control functions are sharper, shorter, and more productive. The rework loop that currently sits between design completion and control function sign-off shrinks significantly.
The key design decisions remain the architect’s. The platform choices, the domain boundary calls, the build versus buy judgment. These require the organisational context, the strategic reading, and the delivery risk assessment that lives in the architect’s experience. The agent does not make these calls. It makes the architect better equipped to make them faster and with more confidence.
Artefact generation.
The outputs are produced. Conceptual architecture, logical architecture, key design decisions, options papers, governance papers.
The artefact generation agent has been present throughout the previous four stages, capturing the decisions made, the options considered, and the reasoning behind each call. By the time the architect needs to produce the governance paper, the agent has the material. The architect works through the artefact with the agent, shaping the narrative, confirming the accuracy of what the agent has captured, adjusting the framing for the specific forum the artefact is going to. The document that emerges from that conversation reflects the architect’s judgment and reasoning. The agent has done the assembly and the first draft. The architect has directed it and owns the result.
The documentation burden that currently takes an architect two days of writing time after the design work is done becomes a continuous capture that culminates in a review and refinement conversation. The architect’s name is on the artefact. The architect’s accountability is intact.
The orchestrating layer.
Across all five stages sits an orchestrating agent that manages the flow of the work. It maintains the context of what has been established in previous stages so the architect does not have to carry it manually. It surfaces dependencies between stages when they become relevant. It ensures the discovery work informs the sizing conversation and the sizing work informs the design conversation without the architect having to manage those connections explicitly.
The architect is not operating five separate agent conversations. The architect is in a single continuous working session, directed by their own judgment, with the orchestrating layer translating that direction into the specific agent capabilities that serve each moment of the work.
The Corpus the Agents Need
The agent system described above is only as capable as the data it works from. The cockpit instruments are the corpus. Without them the agents are not amplifying the architect’s judgment. They are generating confident-sounding output from an incomplete picture, which is more dangerous than no output at all.
The corpus for an architect’s agent system has six distinct layers. Each one serves a specific agent. Each one has specific quality requirements. And each one has a specific organisational discipline problem that prevents most organisations from having it in a usable state today.
Current state application architecture.
The discovery agent needs to know what systems exist, what they do, what their technical health is, and whether the organisation’s intent for each system is to invest, maintain, or divest. Without this, the gap map the discovery agent produces is built on an incomplete picture of the estate. Systems that should be flagged as fragile are described as stable. Capabilities that should be marked for divestment are surfaced as reuse candidates.
The discipline problem: application architectures are among the first casualties of delivery pressure. They are created at programme inception and updated inconsistently thereafter. By the time a new programme needs them, they reflect the estate as it was designed to be rather than as it actually is. Closing that gap is not a technology problem. It is a governance discipline that requires someone to own the maintenance of the catalogue as a standing obligation rather than a programme deliverable.
Capability and journey architecture.
The discovery agent maps requirements to capabilities and journeys. The capability catalogue defines what the organisation can do functionally and where those capabilities are implemented. The journey architecture defines how those capabilities connect in the context of customer and business processes. Together they are the map the agent navigates during discovery.
The discipline problem: capability catalogues exist in most large organisations in some form. They are rarely current, rarely granular enough to support the level of mapping the agent needs, and rarely maintained by anyone with a standing obligation to keep them accurate. Journey architectures are more often aspirational than descriptive. They show the journey as it was designed, not as it operates under the pressure of the real estate.
Technology standards and architecture principles.
The solution design agent checks every design option against the organisation’s agreed standards and principles. For this to work, those standards have to be codifiable. They have to be specific enough that the agent can apply them to a design decision and produce a clear outcome: compliant, non-compliant, or requires judgment.
The discipline problem: technology standards in most organisations exist as documents rather than as structured, machine-readable rules. They are written for human interpretation. Translating them into a form the agent can apply consistently is a programme of work in its own right. And standards drift. The document describes what was agreed two years ago. The estate reflects decisions made since then that have implicitly updated the standard without updating the document.
Control function guardrails.
The solution design agent holds the codified guardrails for data governance, security, compliance, fraud, and operational risk. For those guardrails to be applied consistently and in real time, they have to be structured, current, and maintained by the relevant control functions as a live set of rules rather than a static policy document.
The discipline problem: control function requirements exist in large organisations as policy documents, standards frameworks, and the institutional knowledge of the people in those functions. They are not designed to be machine-readable. Codifying them requires a collaborative programme between the architecture function and each control area. That programme requires the control functions to accept that their requirements can be expressed as structured rules, which is a materially different way of working than most of them currently operate.
Architecture decision records.
The solution design agent surfaces precedents from previous decisions as the architect works through options. For this to be useful, the decision record has to contain not just what was decided but why, what options were considered, what the constraints were, and what the outcome was. A decision record that says “we chose platform X” is not useful. A decision record that says “we chose platform X over platform Y because of constraints A, B, and C, having considered the implications outlined in options paper Z, with the outcome that dependency D was accepted” is the raw material the agent can work from.
The discipline problem: architecture decision records are among the most inconsistently maintained artefacts in most organisations. They are produced under governance pressure and then left to decay. The reasoning behind decisions lives in the heads of the architects who made them. When those architects leave, the reasoning leaves with them. The agent cannot reconstruct reasoning that was never captured.
Historical sizing data.
The sizing agent calibrates its estimates against the history of what similar work actually cost to deliver. For that calibration to be reliable, the historical data has to record not just the original estimate and the final cost but the factors that drove the variance. The programme that came in at three times the estimate because of a dependency that was not understood at sizing. The programme that delivered on budget because the team had deep familiarity with the systems in scope. Without the variance analysis, the historical data produces estimates that are precisely wrong.
The discipline problem: most organisations capture final delivery costs. Few capture the factors that drove the variance between estimate and actual in a structured, retrievable form. That data exists in programme retrospectives, in steering committee minutes, in the memory of the delivery leads who ran those programmes. It is not in a form the agent can use.
The honest observation.
The corpus is the single most critical investment that determines whether an AI-first approach to any business process succeeds or fails. The agent system is only as capable as the data it operates on. Getting that data into a state that is current, accurate, structured, and machine-readable is not a configuration task. It is a programme in its own right.
Codifying six layers of organisational knowledge into a form that agents can reliably operate on requires deliberate investment, cross-functional engagement, and sustained governance discipline. Each layer has its own complexity. The control function guardrails require the data, security, compliance, and fraud teams to express their requirements as structured rules rather than policy documents. The decision records require an architectural discipline that most organisations have not consistently enforced. The application catalogue requires a standing ownership model that survives the pressure of delivery.
That programme has cost. It has complexity. It has dependencies on functions outside the architecture team’s direct control. And it has to be completed, or at least substantially progressed, before the agent system can operate on a foundation worth trusting.
The organisation that understands this plans for the corpus programme first. The cockpit cannot be built until the instruments exist.
The System Contract and the Governance Requirement
The corpus determines what the agent system can work from. The system contract determines what it is authorised to do.
The system contract is not a policy document. It is a structural control built into the agent system itself. The boundaries it defines are enforced technically, not through guidance or governance expectation. The requirements coherence agent cannot approve requirements as design-ready. The discovery agent cannot make a reuse or build decision. The sizing agent cannot present an estimate as a commitment. The solution design agent cannot select a platform or make a domain boundary call. The artefact generation agent cannot submit a document to a governance forum. At every stage, the system is designed to prevent the agent from acting, recommending, or generating outputs beyond its authorised scope. The architect cannot accidentally delegate a decision to the agent because the system will not allow the agent to accept it.
This matters because the agent system is capable of generating a recommendation at every decision point. The system contract is not a constraint on what the agent can technically produce. It is the architectural mechanism that ensures the accountability for every decision remains with the architect by making it structurally impossible for the agent to cross the line.
The auditability requirement.
In a manually produced architecture workflow, the governance paper carries the architect’s decision and the architect explains the reasoning in the forum. The same is true in an agent-partnered workflow. What changes is the layer beneath that.
In regulated industries, the agent’s reasoning, the options it surfaced, the guardrails it applied, the conflicts it flagged, the precedents it drew on, cannot simply be present in the workflow. They have to be logged, structured, and immutable. Available for audit. Not reconstructable after the fact from conversation history or session logs that can be modified or deleted. Captured at the point of generation, in a form that can be retrieved independently of the architect’s account of what happened.
This is a first-class architectural requirement for the agent system itself. Not a feature to be added after deployment. The immutable reasoning log is the audit trail that demonstrates, when the question is asked by a regulator or an internal audit function, that the agent operated within its authorised scope, that the architect made every decision the system contract required them to make, and that the design the organisation is accountable for was produced with the agent in a defined and governed role. Without it, the agent system cannot be deployed responsibly in a regulated environment regardless of how well the rest of the architecture is designed.
Closing
The framework this newsletter has applied to business process transformation applies to the architect’s own workflow. The solution architect’s work, from requirements coherence to governance artefact, meets every condition for AI-first transformation. The actor role is clearly defined. The workflow stages are distinct. The corpus, once built, is the foundation the agent system needs. The system contract places the accountability where it belongs. The auditability requirement is an architectural decision, not a governance afterthought.
What the architect gains from the cockpit is not automation. It is concentration. The grunt work of analysis, mapping, pattern matching, guardrail validation, and artefact generation moves to the agent system. The architect’s attention concentrates on the judgment calls that only the architect can make. Getting there requires the organisation to treat the architect’s own workflow with the same rigour it applies to any business process it is serious about transforming. The corpus programme, the system contract, the immutable reasoning log. Real investment, real complexity, and none of it insurmountable.
Any organisation serious about AI-first transformation of a business process will need to work through the same blueprint this edition has described. Corpus, system contract, structural guardrails, immutable audit trail, and the human actor at the helm with accountability intact. The architect’s workflow is not a special case. It is the general principle made specific. And it is as good a place as any to start.
