From prototype to system
An isolated result does not make a project maintainable.
A prototype shows that a model can produce a result in a prepared situation. A system must do so inside a changing project, together with people, data, tools, constraints and real consequences.
A capable model can write code, analyse documents and coordinate tools. If every session restarts from an incomplete description, decisions, corrections, criteria and completed work become scattered across prompts, chats, files and people’s memory.
- the objective exists only in the current conversation;
- useful sources are not separated from assumptions and obsolete material;
- the system does not know what has already been decided or changed;
- instructions and skills accumulate without clear relationships;
- an agent uses tools without distinguishing permitted effects;
- tests inspect the output but not the path that produced it;
- after an error or pause there is no state from which to recover.
A larger model or longer prompt may improve one response. Continuity requires a structure outside the turn that keeps project relationships legible.
Choose the form
Assistants, AI automation and agentic systems support different work.
AI assistant
Responds, analyses, proposes or prepares objects while a person directs the work. It suits activities that need judgement at each step or must remain open to exploration.
AI automation
Executes a defined sequence. The model may classify, extract, compare or generate part of the result while the route and effects are established in advance.
Agentic system
Preserves an objective and state, chooses among available steps or tools and adapts the route to what it finds. It needs explicit sources, responsibility, stopping conditions, verification and recovery.
The most elaborate form is not an automatic goal. Choose according to the work that should become possible and the variability the system must interpret without obscuring causes and responsibility.
Architecture
Nine relationships in an agentic project.
Intent and the result to preserve
“Analyse these files” describes an action. “Keep technical documentation aligned when verified application behaviour changes” connects sources, conditions and continuity to an observable result. Intent remains open to correction when the project reveals new constraints or possibilities.
Object and scope
The system should know whether it operates on a repository, application, process, corpus or service. It also distinguishes adjacent context from what it may change. Understanding can be broad while each material effect retains a precise owner.
Sources and current truth
Code, state, documentation, databases, conversations and services do not have the same authority. The architecture identifies which sources describe intent, own current state or provide history, and how divergence is handled.
State and continuity
Useful state preserves the active object, verified work, current decisions, boundaries and a recoverable next step. It should support re-entry without rereading everything or inventing what happened.
Expertise and skills
A competence stabilises a way of obtaining a result: criteria, sources, transformations, recurring errors, verification and boundaries. It matters when it changes result quality in a recognisable way and can improve through experience.
Tools and actions
Reading a file, modifying code, querying a service, sending a message and publishing a release have different effects. Each tool has inputs, outputs, conditions and an observable effect. Preparing a patch and publishing it remain separate states.
Responsibility and permissions
Every material effect needs an accountable decision, a permitted action, an access boundary and a person responsible for the result in the real context. Precise controls govern the consequential effect without unnecessarily constraining reasoning.
Verification and result trace
The system should show what it observed, changed and checked. Tests, source comparison, file identity, application behaviour and human review reach different levels. A command run, a passing test and an accepted function are not the same event.
Recovery and evolution
A maintainable system can continue after interruption, correct a decision and replace a dependency without losing the project. A real correction may improve one competence, test or relationship without rewriting every connected part.
Practical object
Agentic Project Architecture Canvas.
Use these questions to turn the idea of an agent into a first project object. Answers can be provisional: gaps show what the system must clarify before it acts.
- 01
Project
Which application, repository, process or service should the system support? Who owns its state and decisions?
- 02
Result
Which change should it continue to produce or preserve? How does this differ from a single task?
- 03
Sources
Which files, data, APIs, documents and people contain the necessary information? Which are current, historical or unverified?
- 04
State
What must remain readable after a pause or session change? What is the minimum description of the situation and next step?
- 05
Expertise
Which recurring transformations need a stable method? Which criteria and errors belong in that competence?
- 06
Tools and actions
What may the system read, prepare, modify or execute? What is the final effect of each tool?
- 07
Responsibility
Which actions are internal and reversible? Which need a human decision, another owner or external authorisation?
- 08
Evidence
How will output, path and final state be verified? Which evidence must survive the session?
- 09
Continuity
How does the system recover after interruption? What should be able to change without losing intent, sources and project ownership?
The system supports [project] to preserve [result]. It uses [sources], keeps [state] and applies [expertise] through [tools]. It may perform [permitted actions]; [accountable person] decides [reserved effects]. The result is verified with [evidence] and work resumes from [continuity point].
Illustrative scenario
A development assistant that does not restart from zero.
Imagine a team maintaining a web application. The model can read and write code, but each new session must reconstruct architecture, decisions, open defects and release procedures. Corrections remain in chats and local tests do not show which version is online.
A first agentic architecture can connect:
- 1an entry file that identifies the project, current sources and rules;
- 2a compact state with objective, verified work and next step;
- 3separate competences for diagnosis, modification, testing and publication;
- 4tools with distinct effects: reading, local patch, commit and publication;
- 5tests that verify behaviour and the boundaries of the change;
- 6a trace recording changed files, evidence and final state;
- 7a recovery point for the next session.
The agent can analyse and prepare a correction without automatically receiving permission to publish it. When publication is selected, the architecture adds version identity, release path, online verification and recovery.
Value comes from keeping understanding, decisions, effects and evidence inside the project.
Portability
The project preserves its identity while models and environments change.
Models offer different qualities of reasoning, coding, speed and cost. Intent, sources, state and verification should live in the project so that a suitable model can be selected for each task without giving that model ownership of the project’s continuity.
Portability still requires adaptation. A local coding agent, web application and remote service have different tools, permissions and state surfaces. The project core remains recognisable while each environment receives the inputs needed for its operation.
Project control
Common mistakes when building AI agents.
Using the prompt as the entire architecture
A prompt guides a turn. Current sources, state, tools, evidence and recovery keep the work legible over time.
Confusing memory with conversation history
Keeping every message does not identify what was decided. Useful memory selects necessary relationships and states and preserves their provenance.
Adding tools before defining effects
A list of integrations does not say what the system may do. First distinguish reading, proposing, changing, sending, publishing and spending a resource.
Accumulating skills without evidence
A declared skill does not prove a capability. An observable result must show when it activates, what it transforms and how it is corrected.
Making autonomy an initial requirement
Assistants and supervised automation can create value. Autonomy matures action by action as state, responsibility, evidence and recovery become legible.
Checking only the final answer
A correct output can come from wrong sources or an irreproducible route. Verification should reach the relationships that make the result dependable.
Frequently asked questions
Questions about agentic systems.
Does an AI agent need a vector database?
Not necessarily. Memory should follow what the project needs to retrieve. Structured state, current files, records and named sources may matter more than general semantic search. A vector database is useful when meaning-based retrieval solves a real corpus problem.
What is the difference between an AI agent and an agentic system?
An agent can pursue a task and use tools. An agentic system also connects state, sources, expertise, coordination, permissions, evidence and recovery so that the behaviour can remain understandable and maintainable.
Do I need multiple AI agents?
Only when genuinely different roles or workloads benefit from separate states, tools or verification. Many tasks can be handled by one assistant with well-organised context and expertise. More agents add coordination, cost and failure points.
How can I test whether the system really preserves context?
Pause the work and resume it in a new session. Check whether the system can recover the object, state, sources, decisions and next step without a complete manual reconstruction. Then change an earlier decision and see whether dependent states are corrected.
Can I change the AI model or environment later?
Yes, when project identity and continuity live in sources the target environment can read. Tools, formats and capabilities remain host-specific and require adaptation.
When is an agentic system ready to act without confirmation?
When the exact effect is bounded, responsibility is clear, verification reaches the final state and an error has a proportionate recovery path. Readiness can differ for every action.