The architect decides how a change fits the organization's systems, and which parts of a system may be probabilistic at all. In AI (artificial intelligence) adoption this work moves earlier and becomes queryable: the architect publishes the reference patterns, trust boundaries and asset catalog entries that teams and coding agents reuse. A coding agent can draft an impact analysis or compare design options. It cannot accept a design, own an asset, approve an exception or set a nonfunctional requirement.
Numbers on this page are illustrative.
An architecture that a coding agent cannot query does not exist for the coding agent. Publish patterns, contracts and catalog entries as data with owners, not only as diagrams.
1. At a glance
| Item | Architect |
|---|---|
| Mandate | Make the safe path the easy path: reference patterns, trust boundaries, shared contracts and catalog entries that every team and every coding agent can find and reuse |
| Primary decision | Which components are deterministic and which may be probabilistic, where each trust boundary sits, and whether a change reuses, extends or creates a shared asset |
| First safe win | Publish one catalog entry and one reference pattern with an owner, limits and an example, then point the team instructions file at them |
| Biggest failure mode | Diagram-only architecture: patterns nobody can query, so each team and each agent invents its own version, as with the ten date implementations (illustrative) |
Line: 1st line (design authority inside delivery) · Family: Build · Variants: enterprise architect, solution architect
| Variant | What differs |
|---|---|
| Enterprise architect | Owns the portfolio view: the catalog structure and capability map, reference patterns, standards such as the temporal-domain contract, approved model and provider options with exit plans. Decides across many use cases and retires patterns |
| Solution architect | Owns one solution: impact analysis, data flow, trust boundary, NFR (nonfunctional requirement) targets, the review of the team's reuse decision. Applies patterns and requests an exception when a pattern does not fit |
| Shared by both | Design records are reviewed like code. Exceptions go through the register with an owner and an expiry. Neither approves an exception to their own design |
2. Your journey: first steps to fully adopted
The architect moves from AI-drafted design notes to patterns and contracts that people and coding agents query; each stage adds controls and evidence, never the right for AI to decide where a model may be used.
Start here: your first steps
- Classify five components of one real system as deterministic or probabilistic, with a one-line reason each.
- Draft one ADR (architecture decision record) with an approved assistant from the catalog template, then check every claim against its source.
- Publish one catalog entry with an owner, limits, an example and a review date.
- Point the team instructions file at that entry and at one reference pattern.
Fully adopted: how the work runs
| Moment in the work | Before AI | Fully adopted (Stage 4–5) | Decision that stays human |
|---|---|---|---|
| Requirement to design | Design starts from a blank page; patterns live in slides | On an approved intake card, a workflow assembles the design pack: impact, pattern match, reuse candidates, a pre-filled NFR checklist | Deterministic or probabilistic for each component, and where the trust boundary sits |
| Impact analysis | Days of manual search; misses found in test | An agent drafts it from code search and the catalog, each finding linked to evidence | Signing the impact analysis after checking every finding |
| Build | Each team and each agent invents its own helper | Coding agents query the catalog through the instructions file; architecture rules run as CI (continuous integration) checks | Reviewing reuse decisions as a reviewer who is not the author |
| Exception | Agreed in a meeting; never expires | Register entry with an owner, an expiry and a compensating control; CI reads the register | The review board approves; never the pattern's author |
| Operation | Pattern drift found after an incident | Agents flag drift and stale entries; adoption is reported monthly | Freezing, renewing or retiring a pattern |
What changes for the organization
| Before | After |
|---|---|
| Architecture lives in documents nobody can query | Patterns and contracts are catalog data that people and coding agents find and reuse |
| Duplicate implementations are found in production | Duplicates are blocked in CI and found early by drift scans |
| Trust boundaries are drawn at release time | Trust boundaries are an intake output, set before build |
In any organization
- Who covers it: in a small or unregulated organization, a senior or lead developer holds this seat, and the catalog can be one file in the repository.
- What scales: a review board can become a second senior reviewer, and a threat model a checklist. What never drops: a human chooses where a model may be used, nobody approves an exception to their own pattern, and no model computes a customer-facing value such as the cutoff.
3. Your decisions
| Decision | You own / advise / challenge | Inputs | Escalation | Cannot be delegated |
|---|---|---|---|---|
| Deterministic or probabilistic for each component | Own (solution); the enterprise architect sets the standard | Intake card, risk tier, cost of a wrong answer, need to explain each output | Enterprise architect; AI or model risk for any High-tier use | Yes |
| Trust boundary and data flow | Own the design | Data classification, residency terms, threat model from security | Security challenges; privacy is consulted | Yes |
| Action boundary for an agent (which tools, which scopes) | Own the design; the AI engineer implements | Reference pattern, use-case risk tier, security threat model | Security; AI or model risk for High tier | Yes |
| Reuse, extend or create a shared asset | Challenge: the developer records the decision, you review it as a reviewer who is not the author | Catalog entry, advisory-hook output, impact analysis | Asset owner; architecture review board | No (the developer records; you review) |
| Reference pattern publication, change and retirement | Own (enterprise) | Adoption data, incidents, catalog feedback, provider changes | Architecture review board | Yes |
| NFR targets: residency, latency, unit cost, resilience | Own the targets; the product owner accepts the trade-offs | Product outcome, volumes, provider terms, platform limits | Executive sponsor for the cost envelope | Yes |
| Model or provider option inside the approved list | Advise; platform runs the gateway; third-party risk approves the vendor | Tool evaluation decision record, benchmark, exit plan | Architecture review board, third-party risk | Yes |
| Exception to a standard | Advise; the review board approves | Reason, owner, expiry, compensating control | Second line for customer-facing assets | Yes |
4. Two kinds of adoption
| Kind | What it means for the architect | Example on this site |
|---|---|---|
| How you work with AI | AI drafts impact analyses from code search and the catalog, compares design options, summarizes long standards and drafts ADRs (architecture decision records). You check every claim against its source before you sign | An agent lists every repository that formats the due date; you confirm each hit before it enters the impact analysis |
| What you design that contains AI | Reference patterns for AI systems. Each pattern fixes the trust boundary, data flow, action boundary and NFRs before a team builds | The governed assistant pattern behind the internal policy assistant: approved index only, citations, abstention, no write tools |
Deterministic or probabilistic
This is the architect's first AI decision, and it is made per component, not per system. A deterministic component gives the same output for the same input and can be explained line by line. A probabilistic component (a model) can vary and can be wrong in new ways. See when not to use AI.
| Question | If yes | Due-date example |
|---|---|---|
| One correct answer defined by contract, law or a calculation? | Deterministic code | payment-schedule-service alone computes the cutoff; shared-datetime only formats it. No model computes or formats either value |
| Same output every time, explainable line by line, kept as a record? | Deterministic code | Statement text is a snapshot under records management |
| Unstructured input, and a human checks the output before it matters? | A model is a candidate, behind a trust boundary | Staff questions to the policy assistant, with citations and abstention |
| Output reaches a customer directly or drives a customer outcome? | High tier: keep a deterministic core; AI is advisory only, with independent validation | A model drafting reminder wording would make that wording High tier; the date inside it stays computed by code |
| A rule table or a process change removes the need? | Do that first | The "due date shown a day early" defect needed a type, not a model |
Reference patterns
A reference pattern is a reusable design with fixed boundaries, published in the asset catalog. Teams start from it; an exception is needed to leave it.
| Pattern | Use when | Boundaries fixed by the pattern | Status (illustrative) |
|---|---|---|---|
| Coding agent to pull request | Teams delegate code changes | Sandbox, synthetic data, no production credentials, the PR (pull request) is the only output, CI (continuous integration) and branch protection enforce | Supported |
| Governed assistant (RAG, retrieval-augmented generation) | Staff ask questions of approved documents | Approved, versioned index only; the user's own entitlements apply; citations; abstention; no write tools | Supported, Medium tier |
| Deterministic core, AI explanation | A customer-facing value must be exact | Code computes the value; a model may only draft explanatory text, under High-tier controls and human review | Pilot |
| Agent with bounded tools | Multi-step internal workflows at Stage 4 | Allow-listed tools, authorization at execution time, idempotency, spend limits, kill switch, human approval for consequential actions | Pilot, Stage 4 teams only |
| Batch summarization with sampled review | Large volumes of internal text | No customer-facing output; sampled human review; source links kept | Supported |
Nonfunctional requirements for AI components
| NFR | Question the design must answer | Target (illustrative) | Who verifies |
|---|---|---|---|
| Data residency | Where do prompts, retrieved text, outputs and traces live, and does the provider keep any of it? | Approved region only; no provider retention for Confidential data | Privacy, third-party risk |
| Identity and least privilege | Whose identity does each tool call use? | The end user's entitlements, checked when the tool runs | Security |
| Latency | What does the user wait for, and what happens at the limit? | 95th percentile under 4 seconds; fallback after 8 seconds | Platform, QA (quality assurance) engineer |
| Unit cost | What does one answer or one task cost, at expected volume? | Cost per answer stated and budgeted per use case | Platform and FinOps (cloud financial operations) |
| Resilience | What happens when the model, the index or a tool is down? | Non-AI fallback path; no customer-facing dependency on the model | Production support |
| Observability | Can one trace join the request, versions, retrieved sources and output? | Trace on every call, retained per the records rule | Platform |
| Kill switch and recovery | Who can turn it off, how fast, and what remains? | Off per channel within minutes; tested each quarter | Production support, release manager |
| Portability | What breaks if the provider or model changes? | Prompts, evaluation sets and tool definitions held in team-owned files; exit plan written | Enterprise architect |
Owning the catalog
Architecture owns the catalog's structure. Each asset owner keeps their entry current. See reuse first for the eight layers.
| Catalog field | Why the coding agent needs it | Kept current by |
|---|---|---|
| Capability and status | The advisory hook matches on capability and must never recommend a deprecated asset | Asset owner |
| Limitations | Stops the agent from using an asset outside its scope | Asset owner |
| Assurance level | Tells the reviewer whether the asset is fit for customer-facing use | Architecture with security |
| Review date | A stale entry is worse than none | Asset owner; architecture checks monthly |
5. Your ladder
| Stage | AI use | Guardrail | Artifact or evidence | Decision relationship | Step-down trigger |
|---|---|---|---|---|---|
| 0 · Foundations | None. You set up the catalog schema, the pattern template and the rule for which tools may touch design documents | Approved tools; design documents classified (most are Confidential) | Catalog schema; pattern template | Enterprise architect owns the schema | Not applicable |
| 1 · Personal productivity | Explains unfamiliar code, summarizes standards, drafts design options; you apply every word | Approved tool cleared for Confidential text; no customer data | Your own draft ADR | You own it; a peer architect reviews as today | The tool's data terms change |
| 2 · Team context | The assistant is grounded in the catalog, the contract and the pattern register, through the instructions file or a catalog tool over MCP (Model Context Protocol) | Read-only catalog access; instructions reviewed like code | Catalog entries with owners; patterns linked from the instructions file | You own the entries; teams are evidence recipients | Entries pass their review date unreviewed |
| 3 · Delegated tasks | An agent drafts the impact analysis end to end, each finding with an evidence link | Evaluation set of past changes with known impact (recall of affected services ≥ 0.95, illustrative); trace kept; your review time planned | Impact analysis draft plus its trace | Solution architect owns and signs; BA (business analyst) consulted; security challenges | A released change had an impact the analysis missed |
| 4 · Agentic workflows | On an approved intake card, a workflow assembles a design pack: impact, pattern match, reuse candidates, a pre-filled NFR checklist and a threat-model stub for security | Read-only tools; no write access to the catalog; spend limit; kill switch | Design pack inside the front-loaded artifact set | Each lane signs its own part; the review board approves exceptions | Model or provider change: step down to Stage 3 and re-run the evaluation set |
| 5 · Scale and sustain | Agents detect pattern drift across repositories and flag stale entries; adoption is reported | Asset ownership funded; material-change process for patterns; periodic review | Pattern adoption report; deprecation notices | You own; internal audit is an evidence recipient | An incident traces back to a pattern boundary |
Stays human-operated at Stage 5: accepting a trust boundary, approving an exception, choosing deterministic or probabilistic for a High-tier component, and retiring a pattern. A named architect makes each of these decisions at every stage.
6. Priority scenarios
| Scenario | Value | Risk tier | Stage | First step | Do not use AI when… |
|---|---|---|---|---|---|
| Impact analysis from code search | Days to hours (illustrative) | Medium (proprietary source) | 3 | Run it beside a manual analysis on two changes; compare misses | The draft would be the only evidence for a customer-facing change and nobody checks each hit |
| Drafting an ADR | Faster first draft; consistent format | Medium | 1 to 2 | Use the ADR template from the catalog as the prompt context | The decision has not been made by people yet; AI would invent the rationale |
| Catalog upkeep | Stale entries and broken examples found early | Medium | 3 | Agent lists entries past review date and examples that no longer compile | The agent would edit entries directly; it proposes, the owner changes |
| Pattern drift detection | Duplicates found before they spread | Medium | 5 | Scan for known anti-patterns, such as a channel computing its own cutoff | Findings would trigger enforcement without a human triage step |
| Threat-model input | Security gets a better first draft | Medium | 3 | Generate the data-flow list and tool inventory for security | You would conclude "no threats" from the draft; security owns the threat model |
| Provider or model comparison | A dated, evidence-based option | Medium | 2 | Use the tools evaluation method with a representative benchmark | Vendor claims would replace your own benchmark |
| Deterministic or probabilistic choice | Not delegated | Not applicable | Any | Decide with the intake card and the table above | Always: a model does not choose where models may be used |
7. The due-date ask from your seat
The architect holds the material artifact in this example: the temporal-domain contract. The full story is in the worked example; this is the architect's path through it.
| Step | Your decision | Input received | Output and evidence | Recipient |
|---|---|---|---|---|
| 1 · Confirm impact | Four display services change (web, mobile, statement-service, notification-service); payment-schedule-service stays the read-only authoritative source; profile-service supplies the zone; nothing else changes | The BA's agent-drafted impact analysis with evidence links and trace | Confirmed impact analysis, each finding verified | BA, product owner, release manager |
| 2 · Fix the domain | The due date is a date-only value; the cutoff is an instant; the zone is an IANA (Internet Assigned Numbers Authority) zone name | The contract clause, payment-schedule-service interface, the three services that converted the due date | Temporal-domain contract v1, published in the asset catalog | All four teams, QA engineer, coding agents through the instructions file |
| 3 · Keep it deterministic | No model in the runtime path; AI is used only in delivery (drafting code, tests, notes) | Intake card (Medium tier for the coding agent) | ADR: "payment-schedule-service alone computes the cutoff; channels only format it with shared-datetime" | Developers, AI engineer, release manager |
| 4 · Review the reuse decision | Agree to extend shared-datetime 4.2 with the display-only formatPaymentCutoff(cutoffInstant, customerZone). It formats the cutoff instant that payment-schedule-service computes and exposes; it never calculates or overrides it | reuse-decision.yaml written by the developer | Review comment and approval on the record (you are not its author) | Developer, library owner |
| 5 · Draw the delivery boundary | The coding agent works in a sandbox with synthetic data; it has no write path to payment-schedule-service or profile-service | Coding agent to pull request pattern | Boundary note in the design pack | Platform engineer, security |
| 6 · Turn rules into checks | Ban new Date(dueDate) and fixed offsets; fail any channel that computes a cutoff itself | Contract v1 | CI rules owned by architecture (reuse first, layers 5 and 6) | Developers, CI pipeline |
| 7 · Decide the exception | The dispute service keeps its strict parser for one quarter (illustrative), with compensating tests | Developer's "create" record and reason | Exception register entry with owner and expiry; the review board approves | Review board, CI (reads the register) |
| 8 · Set the NFRs | Formatting the cutoff adds no remote hop at render time; issued statements stay immutable; missing zone falls back to the state of residence, labelled | Product owner's outcome; statement rules from records management | NFR section of the ADR | QA engineer, production support |
Tier note. The coding agent is a Medium-tier AI use. The change itself is customer-facing and goes through normal change control. These are two different classifications, and the design pack states both.
8. Hand-offs and separation of duties
| Direction | What | With whom |
|---|---|---|
| You give → | Temporal-domain contract and catalog entries | Developers, QA engineers, coding agents via the instructions file |
| You give → | Confirmed impact analysis | Business analyst, product owner, release manager |
| You give → | Reference pattern, trust boundary, NFR targets | AI engineer, platform engineer, security |
| You receive ← | Impact analysis draft; domain questions | Business analyst |
| You receive ← | Threat-model findings | Security |
| You receive ← | Catalog feedback, exception requests, hook and CI events | Developers, the CI pipeline |
| You receive ← | Vendor and data terms, residency conditions | Risk and compliance |
| You challenge | "Create" decisions, NFR trade-offs, patterns used outside their limits | Developers, product owner, AI engineer |
| You are challenged by | Security on the threat model; independent validation on High-tier patterns | Second line |
| You are notified of | Incidents on a pattern, model or provider changes, expiring exceptions | Production support, platform engineer |
Separation of duties. The architect who wrote a pattern does not approve an exception to it. The developer who records a reuse decision does not approve it. A coding agent can draft both; it approves neither.
9. Evidence and records
| Evidence | Produced or consumed | System of record | Retention owner |
|---|---|---|---|
| ADR with the deterministic or probabilistic choice | Produced | Repository, next to the code | Architecture |
| Catalog entry and its version history | Produced | Asset catalog | Asset owner |
| Temporal-domain contract | Produced | Asset catalog | Architecture temporal working group |
| Impact analysis with evidence links and agent trace | Consumed and signed | Requirements record; trace store | Product team; platform for traces |
| Reuse decision review | Produced (review) | Pull request | Repository retention rule |
| Exception entry | Advised | Exception register | Architecture; second line for customer-facing assets |
| Pattern adoption report | Produced | Catalog analytics | Architecture |
| Threat model | Consumed | Security's system | Security |
Retention periods follow the organization's records policy. Templates: asset catalog entry, reuse decision record, hook specification.
10. Skills and learning path
| Level | Skills | Labs | Done when |
|---|---|---|---|
| Foundation | Risk tiers, acceptable use, AI limits (non-determinism, grounding limits, automation bias), when not to use AI | L1 team instructions file | You can classify five components of a real system as deterministic or probabilistic and say why |
| Practitioner | Catalog entries an agent can query; hook specifications; architecture rules as CI checks | L3 advisory hook and CI check | The team's advisory hook returns your entry, and your CI rule fails a planted violation |
| Advanced | Trust boundaries and action boundaries for agents; NFRs for AI (unit cost, latency, residency); portability and material-change planning | L5 approval gate, L6 policy assistant | A pattern you wrote passes security and AI-risk review without a redesign |
11. Measures and incentives
The architect is evaluated on assets other teams adopt, not on documents produced.
| Metric | Definition | Anti-gaming note |
|---|---|---|
| Reuse rate on catalogued capabilities | Changes touching a catalogued capability that reuse or extend ÷ all changes touching it | A rising rate with rising duplicates means records are rubber-stamped; sample them |
| Catalog freshness | Supported entries inside their review date ÷ all supported entries | Bulk re-dating without review defeats it; spot-check entries |
| Duplicate patterns found | New duplicate implementations found by CI or drift scans, per quarter | Should fall; never lower it by relaxing the rules |
| Exception age | Median days open; count of expired exceptions | Renewing without a new reason is not progress |
| Pattern-linked incidents | Incidents whose cause traces to a pattern boundary | Reported without blame, or they stop being reported |
| Design lead time | Intake approved → design accepted | Only meaningful next to the quality rows above |
12. Cost, capacity and workforce
| Item | What to plan |
|---|---|
| Catalog upkeep | Owner time per supported entry (illustrative: 2 hours per quarter), funded as product work |
| Unit cost | Every AI pattern states cost per request at expected volume; platform reports actuals |
| Review load | Agent-drafted impact analyses arrive faster; verification time must be planned, not squeezed |
| Workforce | The role shifts from documents to queryable assets and checks; drafting gets faster, review and stewardship grow |
13. Anti-patterns and stop conditions
| Anti-pattern or trigger | What it looks like | What to do |
|---|---|---|
| Diagram-only patterns | A pattern lives in a slide deck; no catalog entry, no check | Publish it as a catalog entry with an owner and a CI rule |
| A model in the calculation path | A model is asked to compute or reformat a due date | Stop; move the calculation into deterministic code |
| Catalog without owners | The hook recommends an entry nobody maintains | Mark it unsupported until an owner is named |
| Boundary drawn after build | Security sees the data flow at release time | Make the trust boundary an intake output |
| Self-approved exception | The pattern author approves leaving the pattern | Route to the review board |
| Lock-in without exit | Prompts and evaluation sets exist only inside one vendor tool | Keep them in team-owned files; write the exit plan |
| Stop: provider or model change on a pattern | Vendor notice, new model version | Step down affected teams; re-run evaluation sets; material-change review |
| Stop: residency or data terms change | Provider changes where data is processed | Pause new use until privacy and third-party risk confirm |
| Stop: incident on a boundary | An incident traces to the pattern's design | Freeze the pattern for new use; fix; re-review |
14. Action kit and 30/60/90
Copy this card into every design pack for a component that contains AI.
## AI design review card · v1
Use case and intake id: ________ Risk tier (AI use): ____
Change category (change control): ________
Deterministic parts (code only): ________
Probabilistic parts (model): ________ Why a model, not code: ____
Reference pattern used: ________ Exception id (if any): ____
Trust boundary: what crosses it, in which direction, under whose identity
Action boundary: tools allowed, scopes, which actions need human approval
Data: classification, residency, provider retention, minimization
NFRs: latency (p95, fallback after), unit cost, resilience, kill switch, recovery
Observability: trace fields, versions recorded, retention rule
Portability: where prompts, eval sets and tool definitions live; exit plan
Reuse decision reviewed by (not the author): ________
Security challenge done: [ ] Privacy consulted: [ ]
Independent validation needed (High tier): [ ] yes [ ] no, because ____Questions to ask your enablement lead
- Which tools are cleared for Confidential design documents, and under which configuration?
- Can the advisory hook and the instructions file read the catalog today, and who owns that integration?
- Who funds catalog ownership after the first pattern is published?
| Period | Goal | Done when |
|---|---|---|
| First 30 days | One capability made queryable | One catalog entry and one reference pattern with owners, limits and examples; the team instructions file points to them |
| Days 31 to 60 | Rules become checks | Two architecture rules run in CI; the design review card is used on every AI component; impact analysis runs at Stage 3 beside a manual one |
| Days 61 to 90 | Patterns become a product | Pattern adoption reported monthly; stale entries flagged automatically; one pattern retired or renewed through review |