Company brain
Connect approved knowledge, business definitions, relationships, and current operating state so AI works from the company’s reality rather than a generic prompt.
Company brain and memory →AI operating infrastructure
What AI infrastructure should your teams share?
Enough shared infrastructure to give AI the right company context, limit what it may do, recover when work fails, measure quality, and connect cost to business results. Start with one valuable workflow; build reusable foundations as real demand appears.
By Naman Kumar · Updated October 29, 2026
Short answer: a production AI system needs six things around the model: company context and memory; identity, permissions, and approvals; reliable execution; evaluations and monitoring; spend attribution and model choice; and a named human owner. A chatbot alone supplies none of these consistently.
Buying questions
Questions to ask before choosing a platform or partner
Ask which capability already exists in your current stack and which new component is actually required. Ask how the system identifies each agent, applies source permissions, records approvals, prevents duplicate actions, and resumes interrupted work. Ask whether evaluation data represents your own cases, whether production traces can be reconstructed, and whether costs can be attributed to accepted outcomes. Ask what your team will own after implementation and how a model, provider, or implementation partner can be replaced.
A credible answer should name the systems of record, authority boundaries, durable state, test set, monitoring owner, and exit path. “Enterprise-grade,” “agentic,” and “AI-native” are not controls. If the proposed architecture cannot show how one real workflow moves from trigger to verified outcome, it is not yet an operating design.
Hosting and connector boundaries
Should you use hosted, on-premises or hybrid AI?
Private AI, on-premises and cloud describe different arrangements. Map where documents, retrieved passages, model inputs, tool calls and logs are processed. Include support access, retention, backups and the people maintaining the system.
| Option | Decision to verify | Operating responsibility |
|---|---|---|
| Hosted | Which providers receive data, under which terms and configured controls? | Assign vendor review, identity administration and integration ownership. |
| On-premises | Which components stay local, and which external calls or support paths remain? | Assign capacity, patching, access control, backups and recovery. |
| Hybrid | Which data crosses each boundary, for what purpose and with what permission? | Own the policy and connector behavior across both environments. |
Treat MCP as a controlled integration.
For each Model Context Protocol server, record the operator, tools exposed, downstream credentials, permitted resources and logging. Separate the user’s authority from the server’s credentials, review new tools before enabling them and give the team a way to revoke access.
The MCP security guidance addresses issues including token passthrough, session security and scope minimization. Review the actual client, server and authorization design together. Then test the connected workflow using the agent launch checklist and collect provider evidence through the vendor review.
The operating layer
Which capabilities surround a production AI workflow?
Governance
Give every agent an identity. Define what it can read, recommend, change or send, and when a person must approve.
Agent governance →Reliable execution
Use checkpoints, retries, duplicate prevention, fallbacks, and escalation so a partial failure does not create silent damage.
Reliable AI agents →Evaluation
Test representative cases before launch, trace production work, and monitor quality, exceptions, latency, and business outcomes.
Evaluation and monitoring →Cost controls
Attribute usage to a workflow and measure cost per accepted result alongside token usage. Route work to the least costly model that clears the quality bar.
Cost and model selection →Human ownership
Name the executive owner, operational owner, exception owner, and technical maintainer. Infrastructure cannot resolve unclear responsibility.
Accountable AI leadership →Readiness checklist
What should be ready before you scale?
| Decision | Ready when | Warning sign |
|---|---|---|
| Business job | One repeatable unit of work, owner, baseline, quality floor, and desired outcome are named. | “Use AI more” is the objective. |
| Context | Approved sources, definitions, freshness, permissions, and provenance are explicit. | The agent searches every file it can access. |
| Authority | Read, recommend, draft, act, and approve are separated by risk. | A demo credential becomes a production credential. |
| Reliability | Retries, timeouts, duplicate prevention, checkpoints, escalation, and rollback are tested. | The happy path is the only test. |
| Quality | A representative test set and production review process exist. | Success means the output “looks good.” |
| Economics | Model, tool, review, and rework costs are attributed to accepted outcomes. | Teams optimize token price while ignoring retries. |
You do not need to buy six separate platforms. For many mid-market companies, these capabilities can be assembled around existing systems of record and a small number of well-chosen workflows. Design the architecture around the work and its constraints.
Build sequence
How do you build shared infrastructure without overbuilding?
1. Prove the workflow
Observe the current work, define the quality bar, and test representative cases. Keep consequential actions behind approval.
2. Harden the system
Add only the context, permissions, recovery controls, evaluations, and monitoring this workflow actually requires.
3. Reuse what already works
Promote stable connectors, definitions, policies, test cases, and execution patterns into shared infrastructure for the next workflow.
OpenAI describes this shared layer in terms of business context, agent execution, evaluation loops, permissions, auditing, observability, model routing, and reusable agent patterns. That is useful corroboration, not a mandate to adopt one vendor’s stack. See OpenAI Frontier and its guidance on managing AI investments.
Related guides
Go deeper on the operating layer.
Enterprise and regulated environments
The operating foundation must produce evidence, not just functionality.
| Required capability | What it includes | Required outcome |
|---|---|---|
| AI system inventory and risk classification | Named purpose, owner, users, affected parties, models, vendors, data, decisions, jurisdictions, and risk tier. | Leadership knows what exists, which controls apply, and who may approve production use. |
| Security and privacy architecture | Enterprise identity, least privilege, encryption, environment separation, data minimization, retention, residency, deletion, and incident access. | Sensitive information is used only for the approved purpose and unauthorized access can be prevented and investigated. |
| Lifecycle and change control | Documented requirements, validation, versioning, release approval, canary deployment, rollback, decommissioning, and supplier-change review. | Every production result can be tied to an approved configuration, and unsafe changes can be stopped or reversed. |
| Operational resilience | Durable state, backups, tested recovery, provider fallback, capacity limits, escalation, incident response, and continuity ownership. | Critical work remains available or fails safely within agreed recovery objectives. |
| Evidence and oversight | Evaluation records, logs, approvals, action receipts, exceptions, human decisions, complaints, incidents, and periodic management review. | Operators, auditors, and regulators can reconstruct material behavior and verify that controls worked. |
Applicability matters: “regulated” is not one universal checklist. Required controls depend on the workflow, affected people, data, sector, geography, and whether the system is advisory or makes consequential decisions. NIST’s voluntary AI RMF organizes work around Govern, Map, Measure, and Manage; ISO/IEC 42001 defines an organization-wide AI management system; laws such as the EU AI Act add use-case-specific duties. Treat these as inputs to a qualified legal, security, privacy and compliance review. They do not replace advice on the obligations that apply to your business.
Primary references: NIST AI Risk Management Framework, ISO/IEC 42001, and the EU AI Act.
Build it around your company
Company AI infrastructure, built for your team.
Explore hosted, on-premises and hybrid options, with control over models and data and workflows connected to your business tools. Connect shared AI capabilities to the systems and work your business depends on.
See the infrastructure offerShared foundations in practice
The agent coordination case study shows persistent context, explicit handoffs and checks tied to file versions. It is one part of shared AI infrastructure: preserving decisions and checking work as several agents contribute.
One implemented architecture, with its boundary
In the agent work, a local workspace and MCP server share SQLite state. An optional hosted adapter adds OAuth/PKCE and calls the same store; cloud mode excludes host-only tools. The test record checks authentication, state persistence and replay behavior in that implementation. This is a work-coordination component, not a complete enterprise platform. Your gateways, company knowledge, identity provider and operational integrations remain separate architecture decisions.
Build for the teams that need it.
Use the enterprise path when several teams need shared foundations. Use the growing-business path when the first priority is one operating workflow. The company-brain guide remains focused on knowledge and context.