AI development needs a memory — otherwise you pay for it in tokens

The debate about AI in development has been circling the wrong question for two years. Whether a model writes good code is settled — it writes good code. The question projects actually fail on is a different one: how does the agent know what your system does?

In an SAP landscape that is not academic. A feature carries special logic because a plant was added six years ago. A Z program exists because a standard process didn’t fit. A process runs differently in three company codes. None of that is in the code, and where it is written down at all, it sits in a ticket nobody can find anymore.

Where the tokens actually go

Look at any agent session. The share that actually writes code is small. The bulk goes somewhere else: listing directories, opening files, reading search hits, discarding them, digging deeper. The agent assembles its picture of the world from whatever it happens to find — and stops when it believes it has enough.

That has three cost centres, and only one of them shows up on the invoice.

First, the direct cost. A context window full of search hits is paid for again at every subsequent step, because it is carried along. Anyone running agents at scale notices this on the monthly bill before they notice it in the latency.

Second, quality. A model that assembles its own context works with whatever was on top. The second-best hit looks plausible, and the answer built on it looks plausible too. That is precisely the problem: wrong context does not produce an error message, it produces a well-written wrong statement.

Third, repeatability. What one session worked out laboriously stays in that session. The next agent — or the same one tomorrow morning — starts from zero and pays the search cost a second time.

The real problem isn’t the model

It’s where the knowledge sits. System knowledge lives in three places today, and none of them was built for a machine:

• In someone’s head. The colleague who knows why the credit limit check looks the way it does. Not queryable, often no longer with the company.
• In prose. Confluence, SharePoint, a PDF from 2021. An agent can read it and cannot assess it — it has no way of seeing whether it still holds.
• In the system itself. Tables, code, configuration. Complete and true, but without business meaning. That ZSD_CREDIT_CHECK exists says nothing about what it is for.

RAG over the Confluence archive doesn’t solve this, it amplifies it: now the agent gets stale prose with a high similarity score. The trust problem doesn’t shrink — it just gets faster.

What a tool has to deliver

If you want to organise AI development seriously, the agent needs a source with five properties. Fewer will not do.

1. Queryable, not searchable. Not “find documents about credit management” but “which capability is this, which features hang off it, which custom developments overbuild them, what is open”. One question, one answer, no ranking.

2. Current, because it keeps itself current. The technical layer has to carry itself forward from the system — which features exist, what is used, which code is there. Anything maintained by hand is wrong on day two.

3. Writable. This is the part most approaches leave out. What became clear about a feature during implementation has to end up on that feature — written from the context in which the work happened, not three days later from memory. Otherwise you raise efficiency once and lose it again over time.

4. Shared. A source of knowledge only one developer can see is a notebook. What one agent found out yesterday, a colleague’s agent has to find waiting for it today — otherwise ten people work out the same thing ten times and none of it adds up. The value only appears with the shared surface: one place everybody points at, which does not forget between two sessions.

5. Bounded. An access through which a model reads system knowledge is a company decision, not a developer’s installation decision. Who may see what, for which tenant, and may source code leave at all? Those questions belong in the access itself — not in a policy nobody enforces on someone else’s laptop.

And if the agent is hooked into the system anyway?

Plenty of shops connect their agent straight to the SAP system — through ADT, through their own MCP integration, through a script. That is a decision every company makes for itself, and there are good reasons for it. What tends to get conflated, though: live access gives the agent reach, not orientation.

It can now read everything. So it reads everything. A model let loose on tens of thousands of tables and objects has not been handed a map, it has been handed a bigger maze — and the search problem from above doesn’t shrink, it gets more expensive. That ZSD_CREDIT_CHECK exists it can now find out for itself. What it exists for, still not.

The two are therefore not alternatives but two different jobs. A client can talk to several sources at once: one for access to the system, another for the question of what the thing it sees actually means. Having both wins at both ends.

For the source of knowledge, though, what holds for any analysis of your data still holds: Conjola works exclusively on extracts — no live access, no way back, a defined scope. Why that separation is not negotiable for the analysis itself is covered in attached vs. detached.

What this looks like with Conjola

Conjola holds exactly that source: a feature map of what is implemented and used, the custom developments with their business context, the processes from real document flows, and a knowledge base where the functional specs sit next to the data they are about.

Through MCP access your coding agent queries all of it directly — and writes findings, answers and status back. The tenant is fixed to the token, read-only is the default, enabling happens at tenant level, and whether your custom code may leave is a switch of its own.

The effect is unspectacular and exactly the one you want: the agent stops searching and starts asking. And what it learns along the way is still there tomorrow.