Insights.

The natural place to find the owner is the business function the system serves. The person who knows what a correct output looks like is the person who can judge whether the system is still producing one, and that judgment is most of the job. Running the evals is an extension of the owner’s own work, the way the owner uses AI to perform the duties of the role. And just as with the performance of the AI system itself, the owner is responsible for maintaining the eval system that measures it.

The person who knows the work best is rarely the person who knows how to test an AI system. Building and running an eval system is technical work, and it is a tall order to ask everyone who builds a Skill or an agent to learn it. That is why the organization should have someone everyone can reach out to for help: a person or team that helps build the eval system for anyone who needs one, whether it is for a simple Skill or a complex AI agent.

The help stops at the golden dataset. Only the owner knows what a correct outcome looks like at each step of the work, so the owner writes the examples, keeps them up to date when the process changes, and reads the results when the evals run. A failed test only means something to the person who can say whether the failure matters. The rule is simple: the eval system can be built with help, but the golden dataset belongs to the owner.

A failed test only means something to the person who can say whether the failure matters.

The closest existing role is a manager with a new employee. The manager trains the person before trusting them with real work, retrains them when the process changes, and keeps checking the quality of their work rather than assuming it stays good. Owning an AI system is the same job. The evals are the training check, the reruns are the retraining after change, and reviewing samples of the system’s real output is the quality assurance. None of it is new management practice, just the ordinary supervision every organization already applies to people, extended to a system that will not raise its hand when it is struggling.

One person, not a department

Assigning a system to “the AI team” or to a specific department can look like naming an owner, but work that belongs to a group belongs to no one in particular: each member reasonably assumes someone else is watching.

A single owner changes this in two ways. The first one is pressure. The owner knows that if and when the system fails, it is their own neck on the line, and nothing does more to make sure the testing and the reviews actually happen.

The other is memory. Every system accumulates knowledge that never gets written down: the edge cases to look out for, the failure modes it has shown before, the change that broke it last time. In our experience, it is often easier to have a single person carry the memory of one system instead of sharing it with a team. With that said, of course more than one person can build an AI system, but a single person should own it.

Work that belongs to a group belongs to no one in particular. More than one person can build a system, but a single person should own it.

Track who owns what

A register is a pretty useful thing to have in place here: a list of every AI system you have in production, who owns it, and how it is tested. It sounds like bureaucracy until you consider the scale. An organization that gets serious about this will not stop at five systems; it will roll out hundreds, maybe thousands, of Skills and agents built by people across the business. At that point, being able to look up who answers for a system without having to investigate first is worth a lot, and a system with no name against it becomes visible instead of forgotten.

The register also has to be kept alive. People leave, people change positions, and a system can end up owned by someone who no longer has anything to do with the work. When that happens, go through the register: offboard the person from the systems they own, and onboard whoever takes over as the new owner. It belongs in the same routine as removing access when someone leaves. A system whose owner has moved on has no owner at all, and the register is where you catch it.

That is the point of writing the name down. When a system fails, or its owner disappears, nobody has to wonder who it belongs to.

Organizations should keep the layers separate deliberately. Aggregate reporting answers almost every management question and can be shared widely. Content retrieval should sit with a small number of named people, granted the narrowest permission the task requires, with read access and deletion access held as separate credentials so that a leaked read credential cannot destroy data. Each retrieval should have a stated reason recorded before it happens. Use of the interface is itself logged, so that log can serve as the audit trail.

A policy prohibiting personal use does not prevent it. It only ensures people do so believing nothing is stored.

The employee side of this should be settled before the feature is switched on. People will use work accounts for personal matters, and a policy prohibiting it does not prevent it. It only ensures they do so believing nothing is stored. Retrieving and reviewing conversations is processing of personal data, which means it requires a defined purpose, and employees need to be told what is retained and who is able to reach it. Organizations should involve legal or the data protection officer before enablement, and in several European countries employee representatives have a formal right to be consulted before monitoring capability is introduced at all. Clear notice at rollout does more practical work here than any policy clause.

What your agents are doing

Permissions define what an agent is allowed to do. They say nothing about whether its behavior inside those permissions is correct. An agent can remain entirely within what it was authorized to do and still repeat the same failing tool call for an hour, work from a misread instruction, or take an action that is permitted and obviously wrong to anyone watching.

The instruction an agent follows is also not always the one the organization gave it. An agent that reads a repository, a ticket, a web page or an attached document is reading text that can itself contain instructions, and it may act on them using access it was legitimately granted. When that happens, no permission has been exceeded and no control has failed. Establishing what occurred depends entirely on a record of what the agent actually did, and that record has to exist already.

The answer is a trace, which is a record of the steps an agent took: which tools it used, what it asked them to do, in what order, and what came back. Tools for this now exist as a product category, usually sold as agent observability, and many organizations will find that their existing monitoring supplier already offers it. The choice that matters more is the format that record is kept in. A shared open standard for agent activity is emerging, and organizations should ask for their agents to be recorded in that format rather than one supplier's own, so the history stays readable if they later change tools. The standard is still developing, so expect some rework as it settles.

A record is only useful if it points to someone. Agents should run under an identity that belongs to a named person or team rather than a shared account used by everyone, because a record that leads back to a shared account supports neither an investigation nor a conversation about who should have caught the problem.

A record that leads back to a shared account supports neither an investigation nor a conversation about who should have caught the problem.

Two records are available, both have to be switched on, and neither is retroactive. The first is the retained transcript of a session, retrieved through the interface described earlier, which is the recommended route for reading back the content of Claude Code and Cowork sessions. The second is a live stream of events sent to the monitoring systems the organization already runs, and that is where the operational detail sits.

For Cowork, an administrator enters a single collector address in the organization's settings, and nothing is exported until they do. Once it is set, the stream covers the prompts people submit, every tool and connector call with its parameters and whether it succeeded, the file paths Claude touched, which skills and plugins ran, whether each action was approved by the person, rejected, or allowed automatically under existing permissions, and the model, tokens, estimated cost and duration of every request. Two defaults should be decided deliberately rather than discovered later: the full text of prompts is included, and so are user email addresses. Organizations that do not want either sitting in their monitoring systems should filter or redact at the collector before anything is stored.

Claude Code streams comparable events, but it is configured on each machine through environment variables, so an organization that leaves this to individuals has no assurance the telemetry flows at all or reaches the intended destination. It should be set through managed settings, which also prevent a developer redirecting the stream elsewhere. Prompt and response text is excluded here by default, so including it is a deliberate choice. Even without it, the stream shows which tools ran, whether each was approved or refused and on what basis, cost and token use per request, connector connections and failures, and when someone switches a session into a mode that stops asking for approval. That last signal is worth an alert.

Hooks are the measure most specific to agents. A hook is a rule that runs at a set point in the agent's work, usually just before it uses a tool, and it can record the attempt, pass it to a service the organization runs for a decision, or refuse it. Distributed through managed settings, the same rules apply to everyone and cannot be switched off locally. The event stream also reports which hooks are registered on each machine and how often they blocked something, so an organization can confirm its controls are running rather than assume it. They remain something short of a guarantee, because a hook can fail quietly and let an action through, which is why anything that must never happen belongs in the permission rules from the first paper.

For Claude itself, the retained record of chats, files and projects covered earlier is the equivalent. Across all three, the cost figures in these streams are estimates rather than billing records, and the records themselves hold the same sensitive material as an employee's chat history, so their retention and access should be decided at the same time and to the same standard.

Whether the work was done correctly

There is one thing neither of these records can tell you. Usage data shows what employees asked for and what they got back, and an agent's record shows the steps it took. Neither tells you whether the work was any good. An agent that finishes a job and reports success has only told you that it thinks it finished. The problems hardest to catch are the ones where nothing appears to go wrong, such as a document shortened in a way that cuts an important condition, or a customer record updated with something that looks right and is not. Every step finishes, and the record looks exactly as it would if the work had been done properly.

Checking the work is therefore a separate job from watching what happened. Organizations should take a sample of what their AI produces on a set schedule, check it against what a good result should look like, and give the findings to someone who can do something about them.

Almost none of these records can be created after the event. They belong in the rollout plan, not in the response to the first problem.

What you want to be able to find out later

Underneath all of this is a single decision about what the organization wants to be able to find out later. Almost none of these records can be created after the event, so they belong in the rollout plan rather than in the response to the first problem. That means switching them on before people are given access, keeping the ability to see patterns across the business separate from the ability to read one person's conversations, and setting up the recording for agents centrally instead of leaving it to each machine.

None of this acts on what it finds. A record nobody reads only helps after something has gone wrong, so someone has to be responsible for reading it and for what happens next. That is the subject of the final paper.

These controls can also be applied at different levels. Developers may have local settings, teams can define shared project rules, and organisations can deploy managed rules that override both (Fig. 3). For enterprise deployments, the organisational layer is the critical one because it ensures that a prohibited action remains prohibited regardless of who is using the tool or how their local environment is configured. The same principle applies to bypass modes intended for isolated testing: if they are not acceptable in a managed environment, the organisation should disable them centrally.

There is also value in a second technical boundary below the agent's permission rules. Commands can be constrained by the operating environment itself, so an attempted action can still be prevented from reaching a sensitive file, database or server. This reduces reliance on any single control and is particularly important for irreversible actions.

The operating model should therefore be simple: allow routine and reversible actions, require approval for consequential actions, and technically block actions that should never occur. This structure should extend beyond coding tools as well. Access to models, tools and capabilities should follow enterprise roles and identities, with access removed through the company's identity system and actions retained in an audit trail.

What it is allowed to spend

The same principle applies to cost. If employees can consume paid AI usage without predefined limits, the organisation has effectively delegated budget control to individual usage patterns.

Recent examples of very large AI bills illustrate the problem: the system does not need to malfunction for spend to get out of control. If no limits are configured, employees can continue consuming because the platform is behaving exactly as designed. Cost governance therefore needs to be configured before usage scales, not introduced after the first unexpected invoice.

The first control should be an organisation-wide default limit so that no user can consume indefinitely simply because no specific policy was assigned. From there, limits can be differentiated by group and, where necessary, by individual. The objective is not to constrain productive use, but to ensure that unusually high consumption becomes an explicit decision rather than an unnoticed consequence of the rollout.

In practice, usage is rarely distributed evenly. A relatively small group of employees may consume several times more than the typical user because their work genuinely benefits from heavier use. A single limit across the organisation therefore tends to be either too restrictive for power users or too generous for everyone else. A small number of usage tiers is usually more practical, with lower tiers based on normal consumption and a higher tier set as a circuit breaker rather than a target (Fig. 4).

How those limits are managed matters. If one employee repeatedly reaches a ceiling, that usually indicates that the person belongs in a different tier. If an entire group consistently approaches its limit, the tier itself may need to be adjusted. Individual exceptions should remain explicit rather than gradually inflating the limits for everyone.

Usage controls should also be preventive rather than purely observational. Warnings before a user reaches a cap and checks before each request limit the financial impact of abnormal consumption. A cost dashboard is useful for oversight, but it should not be the mechanism that discovers uncontrolled spend after it has already occurred.

What it is allowed to reach

The third boundary is the systems and data an agent can access. Every connector to email, shared drives, code repositories or external services creates another path through which sensitive information can enter or leave the AI environment.

Connectors, including those built on standards such as MCP, make it increasingly easy to give agents access to enterprise systems. That flexibility is useful, but it means organisations need an explicit approval model for which connections are permitted. Being available in a directory or technically compatible with the platform should not be treated as equivalent to internal security approval. A connector should be assessed before deployment based on who built it, what systems and data it can access, which actions it exposes and where information can move.

Access should then be granted narrowly. Different roles may require different connectors, and permissions should be limited at the action level where possible. An agent that needs to read email, for example, does not automatically need permission to send it. Likewise, an agent that needs to inspect tickets does not necessarily need permission to modify them. Write actions should require human approval unless there is a clear reason to automate them (Fig. 5).

Where possible, connector access should also be tied to the company's identity and access management system so that changes in a person's role or employment status are reflected automatically. In coding environments, organisations can go further by maintaining an approved list of external servers or services and preventing developers from adding unapproved connections locally.

Permissions determine which systems an agent can reach, but organisations also need controls over the information moving through those connections. Hooks can inspect tool calls before data is sent or before returned information is acted upon, and can block transfers that contain credentials, customer records or other restricted data. More contextual controls can be added where fixed rules are insufficient, including guardrail agents that assess whether information is sensitive based on its meaning rather than a simple pattern match.

The governing principle is to approve connections before deployment, grant the minimum access required, use read-only access where possible, and inspect the data moving through higher-risk integrations. Approval is not a permanent security guarantee; the organisation still needs controls over how an approved connection is used.

Rules and permissions come before you roll out seats to the rest of the organisation, not after.

Worth getting right

A lot of leaders are thinking about this right now. That makes sense. Once an AI agent can act, not just answer, the rules around it matter as much as anything else in the rollout.

This is where AI governance has to start. Decide the rules first, and you know what your AI is allowed to do. Rules and permissions come before you roll out seats to the rest of the organisation, not after, and not while it is already underway.

Knowing what an agent is allowed to do is not the same as knowing what it is actually doing. That is what we will look at next.

Eval 2: grading maintenance and ingestion

A retrieval eval has a blind spot. It checks whether the brain finds the right page for a question. It has no way of knowing whether that page was written correctly in the first place. If the ingestion and maintenance agents are quietly making bad decisions, the retrieval eval only finds out once a user lands on the page they broke.

There is a reason nobody builds this one on purpose. A retrieval eval is easy to picture: ask, get an answer, judge the answer. A harness running in the background doing rewrites and merges was built specifically so nobody has to watch it work.

The judgment call inside cheap work

The second paper argued for small, fast models on maintenance, Claude Haiku or something local like Gemma, because checking a link or flagging a stale date is cheap work and there is a lot of it. That argument still holds. What it leaves out is that most of these tasks have a judgment call buried inside them.

Tightening a page and quietly cutting the one caveat that changed its meaning look the same from the outside. Merging two duplicate pages only works if the model knows which one is actually current, not just which two overlap. Catching a stale page depends on the model recognising that a renamed product or a reworded policy is the same thing wearing a different name.

None of this shows up as an error. The model finishes the task and reports back that it worked, because from where it is sitting, it did.

The model finishes the task and reports back that it worked, because from where it is sitting, it did.

Grading the janitors

Handing the janitorial work to a bigger model erases the entire reason for using a cheap one. What works better is spot-checking a sample of what the maintenance agents did each cycle, with a stronger model acting purely as a reviewer, grading the work rather than redoing it (Fig. 3).

Three things are worth checking regularly: whether a rewrite kept every fact the original had, whether a merge kept the current version rather than the one it happened to be folded into, and whether a page marked stale or fine would get the same verdict from a person looking at it directly. This does not need to run on everything the harness touches. It needs to run on enough of it that a bad pattern shows up before it spreads across the whole brain, with a way of kicking the failures over to a person.

Eval 3: usage and pruning

Some pages earn their place the way the first paper laid out. Some get added because someone was in a hurry, or because deleting felt riskier than leaving it. The only way to know which is which is to watch what happens to a page after it is written, automatically, without relying on anyone to go back and check by hand. The simplest thing worth tracking, and the one that ends up mattering most, is how often each page gets opened.

Start with a counter

That number needs to exist before any of the rest of this works, and it needs to update itself without anyone remembering to do it by hand. Building it means hooking into both paths a page can get opened through (Fig. 4). On the AI side, wherever the retrieval layer pulls a page to answer a query, that call increments the page's counter and writes a timestamp before it does anything else with the content. On the human side it is simpler: hook into whatever file-open event the tool already fires, and point it at the same counter. One page, one counter, fed automatically no matter which direction someone reaches it from. Once that is in place, the number keeps itself current, and everything built on top of it can actually be trusted.

Sorting the pile

Mechanically, the eval starts by pulling the open count for every page over a set window and sorting the pages into rough bands: heavily used, rarely used, never opened. That part is arithmetic, and arithmetic on its own tells you almost nothing useful. Knowing a page was opened twice this year does not tell you whether that is a problem.

Four pages, four verdicts

That is where a model comes in, and its job is to read the page and work out why it landed where it did, because not every rarely opened page means the same thing (Fig. 5). A page opened twice a year might be exactly as rare as it should be: an incident runbook or a compliance edge case that only comes up occasionally and matters completely both times it does. The right call there is to leave it exactly as it is. A different page might sit unused because nobody titled it the way anyone would search for it, or because the language on it drifted from what people actually type into a query. It is not unused so much as unfindable, and the fix is a rewrite of the title and the links pointing to it. Another page barely gets touched because everything it says already lives on a newer page somewhere else in the brain, the same duplication problem from earlier in this series, and the right move there is a merge. And some pages really are just finished. Nobody is asking the question they were written to answer anymore, and the honest answer is to retire them.

Four pages with the same low number attached to them, four completely different conclusions. That is the entire reason this eval needs a model reading the actual content and not a spreadsheet sorting by a count.

A person makes the final call

One boundary matters here. This part of the eval system produces a recommendation and a reason, nothing more. It deletes nothing on its own. Cutting a page is a one-way decision made by a person who can weigh context the eval does not have, and the eval's job stops at putting a clear case in front of that person.

The same run also surfaces the opposite finding, almost for free. Whatever comes back as heavily used tells you where the brain is actually earning its keep. It tells you where to put more writing effort, not less.

This part of the eval system does not have to run on the same cycle as the harness eval. Quarterly is often enough, or whatever cadence fits, so the shape of the brain gets checked as routinely as its content does.

The count sorts the pages. Only a model reading the actual content can say what the number means.

Our own standard

At Heyra, this is not a one-off idea for this series. Every AI system we run, whether it is something internal or something we have shipped to a client, gets an eval built alongside it, and a person stays in the loop on whatever that eval flags. More of how we operate depends on AI every quarter, and the only way we are comfortable with that is by being just as deliberate about who is watching the AI as we are about what we are asking it to do.

What decay actually looks like

Decay rarely arrives as a single obvious failure. It accumulates through small, individually unremarkable problems that compound over time (Fig. 1).

Orphaned pages accumulate in two ways. The first is when content gets added with no links pointing to it from elsewhere in the brain. The AI has no path to reach it, so the page sits there, invisible and wasted. The second is when a file gets moved or renamed and nothing updates the references pointing to it. The page still exists, but every link leading to it now points at nothing. The AI follows the reference, finds no content, and either fails silently or reaches for something else. Both produce the same result: knowledge the brain nominally contains but cannot actually use.

Pages go stale when the business changes around them. A pricing page accurate at launch becomes quietly wrong after a rate change. A process guide reflects how things worked eighteen months ago. The content looks authoritative, because it was written carefully, but it no longer reflects reality.

Contradictions appear when two pages covering related ground get updated separately. One says the refund window is fourteen days. Another says thirty. Neither is flagged. The AI reads both and has to choose, or worse, blends them into an answer that is neither.

This often happens because the same fact lives in more than one place. A pricing rule in the sales guide and also, worded slightly differently, in the onboarding notes. A product specification written twice, last touched on different dates. Duplication feels harmless when the brain is first built. Over time it is where contradictions are born, because two pages covering the same ground will not be updated together, and eventually they will disagree. When the AI reaches for an answer, you want it pulling from a single source of truth, one page that owns that fact, not arbitrating between two versions of it. The fix is not better conflict resolution. It is accepting that two pages on the same topic is almost always one page too many.

Index files drift when pages are added, moved, or removed without updating the index to match (Fig. 2). The index is a central catalog that lists every page in the brain with a short summary of what it contains. When the AI needs to answer a question, it reads the index first to find which pages are relevant, then opens those pages to find the answer. It is the AI's map of what exists and where to look.

When the index falls out of step with the actual contents of the brain, that map becomes unreliable. The AI looks up a page, follows the reference, and finds nothing. Or it never thinks to look for a page that exists but was never added to the index. Either way, knowledge the brain contains becomes knowledge the AI cannot reach.

Each of these is manageable on its own. Together, arriving gradually, they erode the thing that makes a brain worth having: the confidence that what it tells you is accurate.

Why humans have always failed at this

Wiki upkeep has defeated teams for twenty years and the explanation is not that people are lazy or undisciplined. The explanation is structural.

Maintenance is invisible. Nobody celebrates a page that stayed accurate. There is no deadline attached to checking whether a link still works. The person who knows a page has drifted is usually the person least likely to sit down and fix it, because they are busy doing the work the page describes. And when the maintenance does not happen, nothing breaks dramatically. The brain just gets a little less trustworthy, a little less useful, a little harder to rely on, until quietly, people stop consulting it.

Expecting discipline to solve a structural problem is how wikis died before. The answer this time is different.

Build a maintenance system

The right response to a structural problem is a structural solution. The decay patterns described above, broken links, index drift, contradictions, duplicates, stale pages, bloated pages grown through repeated appending rather than rewriting: all of them are repetitive and mechanical. That is exactly what makes them worth automating, and there are three ways to do it depending on how much infrastructure you want to build (Fig. 3).

The lightest approach is Skills. A skill is a written procedure the AI follows when a certain kind of task appears. You describe each maintenance job in plain language once, and the AI executes it the same way every time. A link-checking skill, a contradiction-scanning skill, a staleness-flagging skill. You can start with one and add more as the need becomes clear.

The next step up is Subagents. A subagent runs a job in its own isolated context, independently of everything else. Rather than running checks one after another in sequence, subagents let you run them in parallel. A link-checker and a contradiction-scanner work at the same time, each doing one thing well. The sweep that would take an hour sequentially takes minutes (Fig. 4).

The most automated option is Routines. A routine runs on a schedule without anyone pressing a button. You set a nightly sweep, point it at the brain, and arrive in the morning to a clean brain rather than a list of problems that accumulated overnight.

The right choice is whichever one actually runs. Start with a skill. Automate it into a routine when the habit is proven. Add subagents when the volume justifies running checks in parallel. The maintenance system that ships is the one that keeps the brain worth using.

You do not need an expensive model for janitorial work

Maintenance is mechanical, not creative. Checking whether a link resolves, comparing two pages for contradictions, verifying an index against a directory: these are repetitive tasks with clear criteria for success. They do not need a frontier model (Fig. 5).

Small, fast models like Claude Haiku handle the vast majority of maintenance checks at a fraction of the cost of a larger model. That matters when the checks are running every single day. Teams willing to go further can run an open model like Gemma locally, which brings the running cost close to zero and keeps every pass entirely inside their own environment. For teams with strict data policies, that last point is often the one that makes the whole system viable.

Maintenance is the product

A company brain that is not maintained is not a brain. It is a snapshot. Accurate on the day it was built, quietly wrong every day after that, until the people relying on it learn not to.

The maintenance layer is not the unglamorous part of building a company brain. It is the part that determines whether everything else was worth doing.

At Heyra, this is exactly the work we help our clients build. If you have a brain that is starting to drift, or you are building one and want to get the maintenance layer right from the start, we would like to talk.

An archive and a brain are not the same thing

The first mistake is treating the company brain as a dumping ground. It is tempting. You have years of documents, chat history, meeting notes and internal guides, and the AI is happy to take all of it. So in it goes. The brain grows large and impressive and almost immediately becomes harder to trust.

The reason is that an archive and a brain are built for opposite goals. An archive is judged by how much it keeps. A brain is judged by how well it gets used (Fig. 1). The moment you optimise for the first, you damage the second, because every page you add is one more thing the AI has to consider, and rule out, every time someone asks a question.

So the test for letting something in is not whether it is true, or even whether it is useful. Plenty of true and useful things belong in an archive, not a brain. The test is sharper than that. For any document, ask: what question does this answer, and who asks it?

If you can name the question and the person, it has earned its place. If you cannot, you are not adding knowledge. You are adding weight.

There is a related question worth asking separately: who is the person? A company brain is a shared resource. If the honest answer is that only one person on the team will ever reach for this knowledge, it probably does not belong there. The company brain should hold what multiple people need, what crosses team boundaries, what would be lost if one person left.

A smaller brain built on purpose will outperform a larger one built by default.

Why loose writing is expensive

Once something earns its place in the brain, the next question is how it is written. AI models are verbose by default. Ask one to write a page and it will hedge, repeat itself, and explain a simple point in three different ways to be safe (Fig. 2). The result reads like a lot, but underneath the volume there is often very little. Length without density.

For a company brain, this matters in three specific ways.

The first is speed. A page that takes three hundred words to say what sixty would have covered is a page people learn to dread. They skim, they miss things, and eventually they stop consulting the brain and go ask a colleague instead.

The second is cost. Every word the AI has to read costs something, in time and in money. A brain full of padded pages is a brain that is expensive to operate.

The third is accuracy. This one is the least obvious and the most important. When a page is surrounded by unnecessary text, the AI has more material to fix on, and not all of it is right. Vague sentences, hedged claims, and repeated points all create opportunities for the model to land on the wrong detail and sound confident about it.

The brain bloats one paragraph at a time

Verbose first drafts are a problem you can catch early. The harder problem is what happens during maintenance. When an AI agent updates a page, its instinct is to add. New information arrives and the agent writes a new paragraph, appends a new section, or extends the existing text. It rarely asks whether the old text still needs to be there.

The result is that a page that was once tight accumulates length with each update cycle. After a few months, a page that was written well at the start reads like three versions of itself stacked on top of each other. The most recent information is somewhere near the bottom. The oldest and possibly now-incorrect information is at the top, where the AI reads first (Fig. 3).

This is worth naming clearly because it does not feel like a failure when it happens. Each individual update looks fine. It is only when you look at the page as a whole, six months later, that you see the drift.

The fix is to treat updating and rewriting as the same job. When new information arrives, the question is not only where to add it. The question is what it replaces, what it makes redundant, and whether the page as a whole still reads as a single coherent thing. Instructions to your AI agents should make this explicit.

Appending is the easy path. Rewriting is the job.

Duplication is verbosity at scale

There is a version of this problem that operates across the brain rather than within a single page. The same fact, written twice in slightly different words, in two different places.

It happens naturally. The brain grows, people add pages without checking what already exists, and the AI agents maintaining the brain do the same. A pricing rule lives in the sales guide and also, with slightly different wording, in the onboarding notes. A product specification appears in two places, last updated on different dates (Fig. 4).

At first this looks like harmless redundancy. It is not. Duplication and verbosity are the same underlying problem at different scales, and duplication is worse because it introduces contradiction. Two pages that say almost the same thing will eventually say different things, because they will not be updated together. And when the AI consults both, it has to arbitrate between two versions of the truth.

Treating duplication as a structural problem rather than a tidying task changes how you approach it. It means checking for overlap before adding new pages, not after. It means building maintenance routines that look for pages covering the same ground. And it means accepting that two pages on the same topic is almost always one page too many.

Worth getting right

The company brain is a genuinely powerful idea. A living source of knowledge that your AI systems can draw on to do better work, across every team, every day. But that potential only materialises if the brain is kept clean: the right content in, written tightly, maintained so that it rewrites rather than accumulates, and watched for the duplication that quietly turns a reliable source into an inconsistent one (Fig. 5).

A clean company brain is the foundation of Operational AI: systems that do real work day to day. The agents are only as reliable as the knowledge they draw on, which is why the brain has to be kept clean rather than just built.

At Heyra, this is exactly the kind of problem we work through with our clients. If you have built a company brain and are starting to notice the drift, or if you want to build one and get the foundations right from the start, we would like to talk.

2. The fastest AI step is the one you delete

The biggest speed gains often come from removing AI where it is not needed. If someone asks something off-topic, a fixed reply may be enough. No AI needed. Instant and free. If something can be handled by normal code, use normal code.

If an agent tool does not really need any input from the agent, it probably should not be a tool. The agent has to realize it needs the tool, call it, wait for the result, then continue. But if the data is always needed, it is often better to fetch it upfront and give it to the agent directly.

No extra tool call. No extra waiting. No extra AI step. Before making an AI step faster, ask whether it should exist at all.

Do not ask one big AI brain to do everything. Build small agents that are excellent at one job.

3. Start before the decision is made

Many AI agent systems use what is often called a supervisor pattern. One agent acts like a manager. It reads the user's message and decides which specialist should handle the task. This is useful, but it can create dead air.

A useful pattern is to make a fast early guess. Turn the message into an embedding, a mathematical fingerprint. Train a small classifier to predict which specialist the supervisor will choose. While the supervisor is still deciding, the predicted specialist can start working (Fig. 2). If the guess is right, the answer is already underway. The supervisor keeps final control.

4. Make it fast, but also make it feel fast

Real speed matters. So does perceived speed. The most important number is time-to-first-token: how long before the first words appear on screen? A user waiting five seconds with a blank screen feels like the system is broken. A user seeing words after one second is much more patient.

So we stream words as soon as they exist (Fig. 3). We prefetch data while the user types. Summaries, analytics, and cleanup happen after the answer is shown. If static instructions are kept in the same place every time, the AI service can reuse more work. Same result, lower cost.

5. Measure before you optimize

None of this works without measurement. It is very easy to make an AI assistant faster and quietly make it worse. Every serious AI system needs test conversations with known correct outcomes. Every change should be checked against speed, cost, answer quality, and safety.

This matters because many ideas sound good until you test them. A cheaper model can be slower. A shortcut can break a whole category of questions. A more advanced model can perform worse on a narrow job than a smaller one.

AI coding agents now help run many of these experiments. They make changes, run tests, read results, and compare options. Humans still decide what to ship. Work that used to take a week can often be tested much faster.

Fast agents are not built by choosing a better model. They are built by designing the whole system properly.