Company Context for AI Agents
Company context for AI agents is the permission-aware organizational state an agent needs to understand the company it is working inside. It combines what is known about customers, projects, people, decisions, and current events with evidence about where that knowledge came from.
People sometimes call this a company brain. The useful version is not one giant prompt or a static document index. It is a live context layer that changes as the company changes and can be shared by more than one agent.
What belongs in company context
Section titled “What belongs in company context”Company context spans several kinds of information:
- entities: customers, companies, projects, people, products, incidents, contracts, or other shared objects
- events: messages, ticket changes, meetings, deployments, approvals, transactions, and agent outputs
- durable memory: facts, decisions, summaries, and state worth carrying forward
- relationships: which people, projects, accounts, and events belong together
- permissions: which user or agent is allowed to see each source and act on it
- provenance: the source evidence behind a remembered fact or conclusion
The point is not to put every byte into an LLM context window. The point is to give an agent a reliable way to retrieve the right organizational state when it needs it.
A company brain should stay live
Section titled “A company brain should stay live”A one-time ingestion job quickly goes stale. Companies change continuously:
- a Jira issue moves to blocked
- a customer sends an email
- someone makes a decision in Slack
- a calendar event is rescheduled
- a database row changes
- an agent completes a task or asks for approval
A useful context layer therefore needs both read paths and change paths. Agents should be able to query current context, while feeds and events keep the shared state moving between conversations.
Lobu models this with connections, feeds, append-only events, entities, memory, and behaviors. See Architecture and concepts.
Company context is more than RAG
Section titled “Company context is more than RAG”Retrieval-augmented generation is an important technique for finding relevant documents or text. A company context layer has additional responsibilities.
| Question | Document RAG | Company context layer |
|---|---|---|
| Find relevant text | Yes | Yes |
| Resolve the same customer/project across sources | Not inherently | Yes |
| Track changing state over time | Usually external | Yes |
| Preserve evidence and provenance | Optional | Core requirement |
| Apply user/source permissions | External concern | Core requirement |
| Let multiple agents write durable state | Not inherently | Yes |
| Trigger proactive work from new events | No | Can |
| Govern actions and approvals | No | Can |
RAG can be one retrieval mechanism inside company context. It should not be confused with the complete operating model.
Example: one account across five systems
Section titled “Example: one account across five systems”Suppose an account manager asks an agent: “What changed with Acme this week, and is anything blocking the renewal?”
The useful answer may require:
- a CRM renewal date
- a Jira incident
- a Slack decision
- an email from the customer
- a note remembered by a previous agent
If every source remains an unrelated text corpus, the agent has to reconstruct the account each time. A company context layer resolves those observations to the same organizational entity and keeps the evidence attached.
The agent can then answer from a coherent account state rather than a pile of search hits.
Permissions have to survive retrieval
Section titled “Permissions have to survive retrieval”A “company brain” that ignores access boundaries is not production-ready. If one employee cannot read a private email or restricted project, an agent acting for that employee should not gain access merely because the content was embedded into a shared index.
The context layer therefore needs to carry source and user permissions through retrieval and action. Lobu uses scoped identities and governed access so different agents can share the same organizational model without receiving identical visibility.
How Lobu represents company context
Section titled “How Lobu represents company context”Lobu combines:
- Connections to company systems.
- Feeds that expose collected, streaming, or virtual data.
- Events as append-only evidence of what happened.
- Entities that connect related evidence around shared organizational objects.
- Memory for durable facts and summaries attached to those entities.
- Behaviors that consolidate new events or perform proactive work.
- Identity, approvals, and policy that govern reads and actions.
Existing agents can access that context through Lobu MCP. Managed agents can run under the same company state and policy model.
Company context vs agent-specific context
Section titled “Company context vs agent-specific context”An individual agent still needs local context: its current conversation, instructions, task files, and intermediate work. That is not a conflict.
A healthy architecture keeps two scopes separate:
- agent-local context for temporary work and private conversation state
- shared company context for durable organizational state that authorized agents should converge on
See Shared memory for AI agents for the memory boundary in more detail.
When a company context layer is useful
Section titled “When a company context layer is useful”It is usually worth building when:
- several agents or surfaces need the same organizational knowledge
- context comes from many systems rather than one corpus
- company state changes while no one is chatting with an agent
- permissions vary by user or source
- agents need to act, not only answer questions
- people need to inspect and correct what agents remember
For a single FAQ bot over one public document set, ordinary retrieval may be enough.