The colleague who remembers why

Imagine a small company on the morning its founder finally takes a week off.

There is work to finish, but nothing that should need her. A proposal is nearly ready. A customer wants a minor change. The new colleague has access to the shared drive, the project repository, and the conversations about the account.

Then someone asks whether support is included in the price.

The proposal template says it is. Last year's contract lists it separately. A message mentions an exception, without saying whether the exception survived the negotiation. The person preparing the proposal can find all three. They send the founder a quick question.

Later, an engineer finds an older component that would be easy to replace. There is a newer one, the tests pass, and the change would simplify maintenance. Before merging, someone remembers that there was a reason for keeping the old version. Another message goes to the founder.

By the afternoon, she has answered several questions that took only a minute each. Each answer also required her to return to a client, a negotiation, or a technical decision she thought the company had already finished with.

This is an imagined company. The interesting part is how little has to go wrong for its holiday to become a working day.

When remembering is part of the job

Go back to when the company was two people sharing a desk. The arrangement worked beautifully. Both heard the customer call. Both knew which promise was firm and which was an idea being explored. A raised eyebrow could carry the context that now takes a paragraph to explain.

The company grows. Conversations separate. One person handles delivery, another sales, another the invoices. The founder can still connect their versions of events because she was present when the work was one continuous story.

The new colleague receives its surviving pieces.

There is nothing foolish about asking her for help. It is often the fastest way to get an answer that accounts for the contract, the customer relationship, and the things nobody thought to write down. Her memory has become part of how the business operates.

That usefulness makes the arrangement hard to change. Each interruption is reasonable on its own. Writing a careful explanation takes longer than answering the question. The company can postpone the work of sharing context every time someone is available to supply it.

Eventually, it hires someone to take responsibility for an area, gives them access to everything, and discovers that they still need permission in the form of information.

A folder called decisions

Suppose the engineer suggests putting the important decisions in Git. The team already uses it, Markdown is readable, and changes can be reviewed. A folder appears. People write down the hosting constraint, the reason for the older dependency, and which support commitments belong to which contract.

This helps. The next engineer can inspect the reason behind a choice and the history of its revisions. Preserving and comparing changes is exactly what version control is designed to do.

Then the person preparing the proposal asks whether a particular customer can have the same terms as last time.

The answer crosses the neat boundaries of the new folder. Part of it is a commercial agreement. Part concerns the cost of supporting an old deployment. Part is a promise made after a difficult delivery. A document can record each part, but someone must still connect them to this question and decide whether last year's reasoning holds.

The team could build that process around Git. It could maintain an index, assign owners, define how records are replaced, and teach every agent where to look. That may be a good choice. It is also work that continues after the repository exists.

The founder's memory was doing several jobs at once: finding the relevant episode, recognizing an exception, knowing what changed, and judging what could be shared. Moving the words into files handles part of that work. The rest becomes easier to see once somebody else tries to use them.

Now give the new colleague an agent. It can search the documents and produce a polished proposal quickly. If it retrieves the old template but misses the exception, the team gets a confident draft based on an incomplete account of its own business.

The next useful improvement has to concern what reaches that agent before it writes.

A memory someone else can use

This is where Mana enters the story.

Mana gives connected agents a shared store for decisions, learnings, and other useful knowledge. A record can carry its source and scope, belong to a defined audience, and be corrected under the same identity while preserving its history. An agent can retrieve evidence for a question instead of relying entirely on what happened to be included in its current conversation.

For the imagined company, the support exception would need an explanation someone could act on. Which customer does it concern? What was agreed? Where is the evidence? Has a later agreement changed it?

Those questions still require care from the person recording the decision. Choosing what to keep is part of that work. Mana cannot recover a promise nobody captured. What it offers is a place where the answer can survive a session and become available to another authorized agent.

It also supplies a limited amount of standing context when an agent connects. The broad working rules can arrive early; the details of a particular account can be retrieved when the task calls for them. The person preparing the proposal has a better chance of seeing both the general offer and the reason this customer needs a closer look.

Git can continue to hold the code and its versioned documents. Mana's purpose is to help the knowledge travel between the work that produced it and the work that needs it next.

There is a complication here worth keeping. A company can remember a bad decision very efficiently. It can turn a temporary workaround into a rule, or preserve an explanation after the circumstances that justified it disappear. Giving a record an owner, a source, and a history makes it possible to examine. Someone still has to do the examining.

Good shared memory should make it easier to discover that an old answer no longer applies.

Return to the proposal on the founder's holiday. This time, the colleague finds the exception, reads its reason, and notices that the new request falls outside its scope. They can prepare the ordinary parts of the proposal and ask one precise question about the new commitment.

The founder still gets a message. It concerns a decision she actually needs to make.

That is the change I would want to see before counting the documents stored or the questions answered. Someone else has been able to carry the history far enough to recognize where the company's existing knowledge ends. The conversation can begin there.