The work before the work

Open a new agent session and ask it to continue a project. Before it can do much, there is usually some context to establish: what the project is for, which decisions stand, where the relevant files live, and which tempting approach has already been rejected.

Some of that preparation is necessary. The task may be new, and the agent should inspect the current state. Some of it may be the same explanation given yesterday.

It is easy to lose sight of this work when the final result arrives quickly. The visible task took a few minutes. The user also selected documents, corrected assumptions, repeated a boundary, and checked whether the output respected it.

I would include those steps when asking whether a memory system helps. Otherwise, the comparison can make the agent look faster while leaving its user's day unchanged.

Choose a task small enough to inspect

Start with a repeatable kind of work: drafting a response from an established policy, preparing a bounded code change, or explaining why a project uses a particular approach. Use artificial or appropriately shareable material for the trial.

Write down what a good result must contain and what would make it unacceptable. Include the relevant constraints, not just whether the output sounds convincing. If the task involves restricted records, include the access boundary too; who gets to know explains why that belongs in the result.

Keep the inputs comparable. A second attempt can improve simply because the operator has learned how to ask the question. Giving one setup a more precise task and crediting the improvement to memory would confuse two changes.

The trial does not have to start large. It does have to preserve enough detail that another person can understand what was compared.

Count what interrupts the task

Run the task with the context arrangement the team currently uses. Note the initial explanation, searches, clarification requests, corrections, and review needed to accept the result. Keep the model and tool setup recorded if those could affect the comparison.

Then try the shared-memory arrangement on a comparable task. Supply the same goal, allow the agent to retrieve the relevant decisions, and record the same kinds of work. Include the effort of creating and maintaining those records rather than treating it as free.

The observation I would look for is specific. Did a previously repeated explanation become a retrieval? Did the agent recover the reason for a constraint without asking its author? Did the record remove an ambiguity, or merely produce a longer initial context?

The number of calls can be informative, but fewer calls do not automatically mean a better run. One additional lookup might prevent an expensive correction. Likewise, an answer produced with little context may be cheap because it missed the difficult part of the task.

This is why the unit of comparison should be a result that passes the agreed checks. Cost, elapsed time, and human attention belong beside correctness.

Include a changed answer

A memory system can look useful when every stored record agrees. Give it a more revealing case: correct one of the decisions, then start a fresh task that depends on it.

Can the agent find the current answer? Can it explain the change without treating the earlier record as equally active? Does it preserve the boundary around where the correction applies?

Try an unanswered question as well. The store may not contain enough evidence. A useful result can identify the gap and ask for the missing decision. Filling it with a plausible sentence would make the interaction shorter while leaving the user with more risk to detect.

These checks help separate retrieving text from supporting work. They also expose whether the team is maintaining the material the system relies on. An agent cannot recover an agreement nobody recorded.

Let the result change the setup

Perhaps the trial shows that the shared startup instructions are too long. Perhaps one concise project note helps more than a large collection of disconnected memories. Perhaps a frequently retrieved record is vague enough that the user still has to explain it.

Each outcome suggests a different adjustment. Adding more content is only one possible response. The lesson might be to narrow a record, improve its title, remove duplicate guidance, or capture the reason a decision keeps generating questions.

For a team of parallel agents, look at reconciliation too. Several fast tasks can still produce a slow whole if their outputs need extensive repair. Shared decisions earn their place when they improve that whole, not only when each agent reports completion sooner.

The trial described here is a proposal for evaluation, not a measured Mana result. Its purpose is to make a product claim testable in the conditions where a particular team works.

Return to the founder answering questions during her holiday. A successful change would leave her with fewer repeated explanations and more precise questions about genuinely new decisions. The team would still do research, exercise judgment, and ask for help.

The difference would show up in the work that no longer had to be reconstructed before they could begin.