An AI agent has no memory of its own between two sessions. We preserve the project’s memory permanently through specifications, guardrails, and skills.
Three months after project kickoff, the acceptance test of an AI-developed application revealed something troubling: anyone who changed the invoice number in the URL could see another customer’s invoice as a PDF, complete with address and payment status. We looked for the rule that should have prevented this. Somewhere it should have said: a customer may only view their own invoices. We asked the AI agent that was working on this module at the time. It had no idea — and couldn’t have had one: that session knew nothing of the last one, let alone the one months earlier that should have specified this check. So we searched the specification itself. The rule wasn’t there. Not deleted. Never written down, because it seemed too obvious to everyone to bother recording it.
To make sure this doesn’t happen again, every decision needs a place where even the next, clueless AI agent can still read it.
The Specification – What’s fixed and what’s still open
This is where the business domain of a module is defined: its terms, data, and rules. This also includes the use cases with their acceptance criteria, which precisely describe how the system should behave. This is owned by the business analyst.
Every statement in it falls into one of two categories:
- Invariant: A fixed rule that an implementation may never violate.
- Open Decision: A decision not yet made, recorded with a safe default value so nobody has to guess.
The Golden Rule: write down every business rule and invariant explicitly, no matter how obvious it seems. Whatever isn’t in the specification doesn’t exist for the AI agent.
EXCERPT: FROM THE ORDER DOMAIN MODEL
Order
id: string
accountId: string (owning customer account)
status: placed | shipped | cancelled | refunded
INV-07: A customer may view only orders belonging to their own account.
OD-03: How long does a cancelled order stay visible in the account?
Default: 24 months, pending confirmation from Legal.
EXCERPT: USE CASE ORDER DETAIL
Scenario: Customer views their own order
Given an authenticated customer
When they request an order by id
Then the order is returned only if accountId matches the requester
# enforces INV-07
Scenario: Customer requests an order they do not own
Given an authenticated customer
When the requested order belongs to a different account
Then the response is 403 Forbidden
# enforces INV-07
The Guardrails – The memory that applies to everyone
Above the specification of an individual module sit the guardrails. They form the shared technical standard that every application in the system follows: tech stack, programming language, API design, security, error handling, and logging.
This is defined by the solution architect. It also includes architecture decision records (ADRs) — short entries that capture why a particular option was chosen and an alternative rejected.
The golden rule: define technical standards and security rules once, centrally, for the whole system. Whatever is anchored in the guardrails applies without exception, regardless of what the business analyst happened to think of in an individual use case.
EXCERPT: ARCHITECTURE DECISION RECORD
Title: Integration with SAP S/4HANA
Status: Accepted
Context: Multiple services need data from SAP. Direct point-to-point connections would mean many sets of credentials to rotate and no single place to audit access.
Decision: All integration with SAP S/4HANA goes through SAP Cloud Integration. No service connects to SAP directly.
Consequences: One integration surface to secure and monitor. Slightly higher latency accepted as tradeoff for a single audited path.
EXCERPT: DEFINITION OF FOLDER STRUCTURE
pxp-portal-web (BFF)
├── app/ (Routes & Server Components call microservice directly)
├── app/api/ (Route Handlers, one per client-triggered write)
└── lib/api-client (Typed calls to the microservice)
order-service (Microservice)
├── src/handlers (HTTP routes)
├── src/services (Business logic)
└── src/models (Domain types)
Rule: The browser never calls a microservice directly.
Every client-triggered write goes through a same-origin Route Handler in the BFF.
The UX – What’s allowed vs. how it should look
A visual design carries no memory of its own at all. A Figma design only shows a target state, but never the reasoning or the business logic behind it.
The golden rule: the design shows the how, the specification decides the what. If the two contradict each other, the specification always wins, because it’s the only one that can be explained and traced back.
EXAMPLE: UX ORDER OVERVIEW
The Hands – Two kinds of memory
None of the three human roles (architect, business analyst, UX designer) writes the code itself. That’s handled by a set of repeatable procedures: the skills.
Here the difference between two types of knowledge becomes visible:
- Declarative knowledge (factual knowledge): The specification and the guardrails record what has been decided.
- Procedural knowledge (know-how): The skills record how to actually build something from these requirements.
The Golden rule: define the procedural knowledge (how to build) in repeatable skills, but never let them guess the factual knowledge (what to build). A skill executes rules strictly and stops immediately if a specification is incomplete.
EXCERPT: SKILL DEFINITION IMPLEMENT-USE-CASE
name: implement-use-case
description: Turn an already written Use Case doc into working code against the harness.
instructions:
Before writing any code, trace every Open Decision and Invariant
the Use Case cites. If a citation points to an ID that does not
exist in the Domain Model doc, STOP and flag it rather than
guessing what it might have meant.
Was „STOP and flag” in der Praxis bedeutet: Der Agent bricht die Session nicht ab, er pausiert sie. Die offene Frage geht als Rückfrage an die verantwortliche Rolle zurück, meist an den Business Analyst bei einer fehlenden Anforderung, an den Architekten bei einer Lücke in den Leitplanken. Bis die Antwort da ist, wird nichts geraten und nichts implementiert. Sobald die Entscheidung in Spezifikation oder Leitplanken eingetragen ist, nimmt der Agent die Session mit dem neuen Stand wieder auf.
The Audit – How we closed the gap
When the team investigated the invoice URL security hole, it became clear: it was never the decision of a single module, but a rule that everyone had considered “obvious.”
The problem was fixed in two places:
- Invoice retrieval now checks ownership.
- The rule was added globally to the guardrails.
EXCERPT: GUARDRAILS (ADDITION AFTER THE INCIDENT)
Rule: Any endpoint returning an entity by ID MUST verify that the requester
owns it before the response is built. No exception—not even for internal tools.
The Overview: Three roles, one borrowed memory
An AI agent forgets everything. Every time. So that AI can still develop software reliably within an enterprise, we move the project’s memory out of the volatile chat window and into structured artifacts.
Three human roles define the factual knowledge (what gets built). Repeatable skills provide the procedural knowledge (how it gets built). The agent only borrows this knowledge for the duration of a working session.
In a nutshell
- Borrowed memory: The AI agent has no memory of its own. It reads specifications and guardrails at the start of a session and forgets them again when it closes.
- The golden rule: What isn’t written down doesn’t exist for the AI. In AI engineering, there’s no such thing as “obvious.”
- Engineering instead of “vibe coding”: The difference between trial and error and professional AI development doesn’t lie in clever prompting – it lies in the quality of the specifications and guardrails.
How Diselva can help
Getting started with AI-driven software development is a cultural and process shift. At Diselva, we help you build this foundation:
Anchoring guardrails: We work with your architects to define technical standards and security rules (harness).
Sharpening specifications: We establish structures for use cases and invariants that AI agents understand unambiguously.
Developing custom AI skills: We build the procedures your agents need to code precisely to your specifications.
Lowering context costs: A memory that gets reloaded from scratch at every session has a cost. We structure guardrails and specifications so agents only load what they actually need.
Make your project’s knowledge independent of any single chat’s context window – get in touch.