From agent memory to a Company Brain: keeping business context accountable

01 / FIELD NOTES

Remembering a conversation is only the beginning

An agent can remember a conversation and still act on the wrong business fact. A note may name the previous account manager. A meeting summary may mention a payment that the accounting system still marks unresolved. A policy copied into a prompt may have changed last week.

A Company Brain needs a way to connect context to responsibility: where information came from, who can change it and what an agent should check before relying on it. That is the problem our work on Cortex is designed to address.

02 / FIELD NOTES

Start with meaningful records

ClawVault helped shape our approach to structured context. Its documentation distinguishes kinds of knowledge from the objects used to maintain them. A decision can record a choice, a task can track work and a handoff can carry context into a later session.

For a business, start with the records people already use: a customer, a project, a decision explaining the work and a source that owns its current status. Connect those records so the next person can understand the relationship without reconstructing every conversation.

Sources: ClawVault's types and primitives

03 / FIELD NOTES

Give each fact an owner

Our work on Cortex's Company Brain applies this principle to a shared workspace. Durable context has identity, relationships and review history. Connected systems keep ownership of their operational facts.

An internal note can explain why the team chose an approach without becoming an alternate payment ledger. A project annotation can add useful history without implying that it changed the CRM. A proposed update can be reviewed against its source before becoming shared knowledge.

Before a team puts this into a workflow, we check the actual sources, permissions and supported changes. That gives the deployment a clear boundary and the team a useful set of questions to review.

04 / FIELD NOTES

Distinguish a source update from an annotation

Consider an illustrative account record. The CRM owns the assigned account manager. A shared note explains that the client likes a short written summary before a meeting. The team should be able to maintain that note without accidentally replacing the manager field.

If the source assignment changes, a useful system makes the current assignment visible while preserving relevant explanatory history. It should not restore an outdated business fact just because an older note contains it.

During scoping, we map these responsibilities field by field where needed. That is especially useful when several tools describe the same customer or project with slightly different names.

05 / FIELD NOTES

Connect agents through an explicit identity

Versatly's public Cortex connector repository contains separate paths for compatible editor connections and persistent agent enrollment. Its OpenClaw adapter checks runtime capabilities and uses an owner-approved connection flow.

We check the installed runtime and the intended connection before deployment. Those checks establish which connection path the agent supports and how it identifies itself to the workspace.

For a team, the operating principle is clear: know which agent is connected and what it can access. A restarted session should not silently acquire a new business identity, and remembered context should not grant additional permissions.

Sources: Versatly Cortex connector repository · OpenClaw connector capability checks

06 / FIELD NOTES

Follow one change from request to outcome

Here is an illustrative reporting workflow. A client requests a change to the monthly update. The team captures that request with its source and proposes an updated reporting rule. The account owner reviews it before the next report uses it.

If the request conflicts with an existing instruction, it remains a decision for the owner. If the reporting workflow cannot read a required property, it identifies the gap. If delivery is included, the final check establishes whether the reviewed report reached its intended destination.

Those steps answer separate questions: what was requested, what was approved, what ran and what happened. Keeping them distinct helps the team investigate an incorrect report without guessing which stage went wrong.

07 / FIELD NOTES

Keep a review boundary around shared knowledge

An observation from a conversation can be useful without being ready for everyone to rely on. Give uncertain information a review state, and identify who can resolve it. When two records conflict, preserve the conflict long enough for the responsible person to see it.

The same care applies to audience. Context appropriate for an internal account team may not belong in a customer-facing answer. The workflow needs an explicit view of which records it may use for each audience.

These are operating requirements to agree during setup. They should be visible in the scope and checked with representative records, including a rejected update and a request from someone without the necessary access.

08 / FIELD NOTES

Measure whether the context helps the work

A larger knowledge store is not automatically more useful. Look at whether the next person can find the decision, identify its owner and complete the handoff with fewer unanswered questions.

Useful measures include time spent reconstructing project history, unresolved contradictions, records missing a source and handoffs waiting for an owner. Establish the starting point with your team, then compare the same process after the pilot.

Monthly care can include source freshness checks, connection failures, review queues and adjustments to approved retrieval rules. The proposal should identify which work is included, who responds to exceptions and how the business reviews the result.

09 / FIELD NOTES

Choose one shared context problem

A first Company Brain project can be narrow: account handoffs, operating decisions or the knowledge behind a recurring support question. Pick one process whose information and ownership the team can explain.

Connect the necessary records, agree on the review boundary and test one workflow against them. Expand when the business can see that the context is accurate enough, accessible to the right people and helping a real task.

Bring us a recent handoff that required someone to retell the story. We will help identify the durable context, the live records and the decisions that should stay with your team.