A team plans to change how a service handles cancelled bookings. Its architect has an existing design, several decisions and a list of requirements. An assistant using artificial intelligence (AI) can compare those records, suggest missing questions and help prepare a change. The architect still needs to know which sources the assistant used, which decisions remain open and what the checks show.
AI can assist research, design, delivery and support. The useful starting point is a defined task and a result someone can review. A prompt describes that task. The surrounding tools and service controls determine which records the assistant can read and which actions it can take.
Work within the framework
A Simple Architectural Framework (ASAF) helps the team examine the relevant people, work, information, systems and responsibilities. Its continuing process areas also provide places for AI assistance.
| Process area | Possible assistance | Decision or result retained by the team |
|---|---|---|
| Visioning | Compare needs, constraints and possible outcomes. | Agreed aims, assumptions and questions that need investigation. |
| Transforming | Compare requirements and plans; draft designs, code and checks. | Accepted changes and test results for the version being checked. |
| Operating | Assemble a service timeline, inspect records and check recovery instructions. | The service’s actual state and decisions about response and recovery. |
| Governing | Compare a proposal with principles, owners and earlier decisions. | The responsible person’s decision, reasons and any exception. |
Several of these activities may occur in one small change. The framework does not require a separate agent, document or approval meeting for each row.
This guide concerns AI helping people do architecture work. A service that uses AI to perform part of its own work has additional design questions about its inputs, uncertain output, actions and recovery. The software and business rules guide introduces how to define what an AI step receives, returns and may change.
Give the assistant a useful brief
State the problem, the affected service and the result needed. Supply the current requirements, accepted decisions and the versions of relevant sources. Identify what may change, the actions already authorised and the questions requiring another person’s decision. Set limits on time, tool use and spending where they matter to the task.
The assistant should distinguish a source statement from an inference or proposal. A supplier’s promised response time, for example, is different from a response time observed in a test. Missing information should become a question or an explicit gap rather than an invented answer.
Keep the brief with the work it produced. A later reviewer needs enough information to understand the inputs, the change and the checks. They do not need a transcript of every exchange.
Check the work that matters
Choose checks for the failure being considered. A comparison of requirements and a plan needs a record of which requirements the plan addresses. A booking change may need tests for a duplicate request, revoked access and a response lost after acceptance. A prose edit needs source and language review. Writing a test for every task would add work without necessarily answering a useful question.
A second review can challenge the first assistant’s assumptions. Give the reviewer the requirement, changed material and relevant decisions, and ask for findings with source references. A separate review remains fallible; another model response is not proof of correctness.
Keep deterministic checks outside the model. These apply fixed rules and can check directly whether a result meets them. A quotation checker can verify that words occur in a selected passage. The application must still check permission and current state when applying an accepted change. A convincing explanation cannot substitute for those checks.
What our project work has taught us
Our recorded practice has changed across projects. An earlier prompt-driven development document described an intended sequence: break work into tasks, reproduce a problem, write a failing test and implement the change. Later records describe combinations of planning, implementation, review and checks chosen for the task. Much of this work has been organised through discussion of a particular problem, with the plan and checks adapted as it develops. These experiences are useful to compare. They do not yet establish a complete architecture method.
In cREXX-RAG, a project for retrieving sources and maintaining supported claims, a 17 September 2026 repair clarified what the prompt fields required and corrected how a quotation was matched to a selected source occurrence. An initial test used an old compiled program, so it did not exercise the new assertions. After recompilation, a test exposed the defect. In a small repeat run, a model also produced a plausible quotation from the wrong occurrence, which the quotation checker rejected.
The lesson is to examine both the instructions and the checking mechanism. Improving a prompt, passing a check of the response’s structure and completing the task are different results. The small repeat run did not establish a general model ranking.
The 14 September 2026 record of cREXX performance work retained an observed timing difference whose cause remained unresolved. That record illustrates the value of keeping observations separate from explanations. Reuse valid results when the relevant inputs are unchanged, and choose further checks to resolve a particular question. Those measurements concern the product; they do not measure AI productivity.
Support and uncertain results
If a booking request times out, the support team may not know whether it was accepted. An assistant can assemble the request, receipt, case version and relevant logs. It should report what those records establish and what remains unknown. Repeating an action without checking its outcome could create more work to reconcile.
Read-only diagnosis is a useful task to delegate: it gathers information without changing the service. Check a recovery procedure against the actual environment before proposing its use. The person responsible for the service determines which response is permitted; the tools must enforce that permission.
An AI prompt cannot make a restart safe or establish a cause. The support records should retain competing explanations, contradictory observations and the next check likely to distinguish them.
Useful prompts and records
Choose an asset for the task you need to carry out. The three collections cover generic information technology (IT) governance, delivery and quality assurance, and support. Each pairs a human task brief with an AI prompt template, required inputs, expected outputs and a worked example. Adapt these to your terminology, sources and authority.
The governance collection covers principles, ownership, guidance changes, release preparation and warnings. The delivery and quality assurance collection covers requirements, tests, review and execution state. The support collection covers acceptance, diagnosis, uncertainty, runbooks and measures.
Keep the source asset and edition with an adapted brief or prompt. Supply the actual task details and identify missing inputs. Reading an example does not authorise its execution.
Methodology configuration
Use the shared configuration guide to map these activities to your own method. Choose the scope and timing of each review, how much work to attempt together and who accepts its result. Decide what can be automated and how a local finding can change wider guidance.
Judge the arrangement by accepted outcomes, review effort, rework, defects missed by earlier checks and support cost. Tokens are the units of text a language model processes or produces. Generated text, tool calls and token counts describe activity or consumption. They become useful measures when connected to the result the team needed.