The situation
An AI capability has been approved: a knowledge assistant across the business, agents in customer operations, a shared model platform. Several teams are ready to build. What they lack are decisions. Which model hosting? Where does access control sit when an assistant reads from five systems with different permission models? Is retrieval a shared service or embedded per product? What gets evaluated, by whom, before anything ships?
Without those decisions, teams either wait or decide independently and diverge. Your existing architects know your estate well but have not designed these systems before, and you do not need, or are not ready for, a permanent head of AI architecture. You need senior architecture capacity for a defined set of decisions, by someone who can also prove a design in code.
Bounding the responsibilities
The single most important thing in this contract is the boundary, because architecture roles drift. I work to three rules:
- A finite decision backlog. The contract is defined by a list of decisions, not by a title. When the list is done, the contract ends or a new list is agreed in writing.
- Your decider decides. I write recommendations; your CTO, chief architect or architecture board accepts or rejects them. I hold no authority over teams, budget or hiring.
- Every design ends in an owned interface. A design is not finished until an interface (an API, event contract or schema) has a named owning team who agreed to it.
What the work involves
For each decision in the backlog I set out the options, the trade-offs that matter for your context (cost, latency, data residency, access control, operability, vendor dependency), the evidence and a recommendation. Where evidence is missing, I build a short prototype or benchmark on your data rather than argue from general experience.
Integration designs follow decisions. For AI components these cover data flow from source to model and back, where permissions are enforced, what is logged and retained, how quality is evaluated before and after release, and what happens when a model or tool fails.
The signature deliverable
You end with an architecture decision backlog, integration designs and named implementation interfaces. Illustrative example of a backlog extract:
| # | Decision | Decider | Needed by | Evidence | Interface and owner |
|---|---|---|---|---|---|
| 1 | Model hosting: provider API or private deployment | CTO | Before pilot data | Cost and latency benchmark on sample workload | Model gateway API, platform team |
| 2 | Where document permissions are enforced | Chief architect | Before indexing | Prototype of query-time filtering | Retrieval service contract, search team |
| 3 | Shared or per-product evaluation harness | Architecture board | Before second product team starts | Survey of team needs | Evaluation API and dataset schema, ML team |
Illustrative example showing the format, not a record from a client engagement.
How acceptance is judged
Each decision record is accepted when your decider signs it off. Each interface is accepted when its owning team agrees to it and early implementation conforms to it. At the end, acceptance is simple to check: every item in the backlog is decided, deferred with a reason, or explicitly handed to your architects, and every interface has an owner.
Ownership and handover
Decision records live in your repository or architecture tool, written to your template. Your architects attend decision reviews from the first week, so the reasoning is theirs as much as mine. The handover covers the records, designs, interfaces and owners, any deferred decisions with their triggers, and the risks I would watch.
When to choose something else
If you need someone with organisational authority over AI architecture, that is a leadership appointment; see fractional AI CTO and technical leadership, or the Principal AI Architect route at dipankar.name. If the decisions are made and you need builders, brief the LLM engineer, AI agent engineer or AI platform engineer role.