# Monolith

> Monolith is the Boltcliq context, memory, governance and permissions system for AI agents, with a tool and model gateway.

Canonical URL: https://www.boltcliq.com/products/monolith
Part of: https://www.boltcliq.com/llms.txt

Decide what every agent may know, remember and do. Monolith is the context, memory, governance and permissions system that makes AI agents safe to trust with real business data.
- Filtered: context is limited to what the requester and the agent may see
- Forgettable: memory with retention rules and the ability to erase
- One path: a single controlled route to tools and language models
- Registered: every agent has an owner, version, permissions and status
- An agent should know what it needs, remember what it may, and do only what it is allowed.
### Overview
- An AI agent is only as safe as the data and tools it is given. Most teams start by pasting data into a prompt and wiring a few tools to a model. It works in a demo. In production it raises questions that nobody has answered. Which records may this agent read? What does it remember between conversations, and can that memory be erased? Which models may receive customer data? Who can switch it off?
- Monolith answers those questions in one place. It registers each agent with an owner, a version, a purpose and a set of permissions. When a task starts, it assembles context: the objects, documents and memories relevant to the task, filtered for both the person asking and the agent. Memory has provenance and retention rules, and it can be forgotten when the law or a customer requires it.
- Monolith also sits on the path between agents and everything they touch. Sensitive actions can require human approval, and any agent can be stopped with a kill switch. Monolith governs, and Argus stores and runs. Monolith policy is evaluated through Odin, so there is still only one decision point.
### Monolith in one picture
- Decide what every agent may know, remember and do. Monolith is the context, memory, governance and permissions system that makes AI agents safe to trust with real business data.
- Agents that see only what they and their requesters are allowed to see.
- Memory you can inspect, limit and erase.
- A controlled route to tools and models, with limits, redaction and approvals.
- Schematic of Monolith. Illustrative, not a product screenshot.
### How it works
**Register the agent**
- Every agent is entered in a registry with an owner, a version, a purpose, its permissions and its status. An agent that is not registered cannot get context or call tools. The registry shows at a glance what is in production and who is responsible.
- Collections assistant, owned by the Head of Recoveries, v1.2.
**Assemble context**
- For each task Monolith retrieves the Zeus objects, documents and memories that are relevant. It filters them by what the requesting person and the agent may see. The agent receives a prepared bundle, not a connection to the whole database.
- Load this borrower's repayment history, not their medical notes.
**Route every call**
- Calls to tools and models go through the gateway. The gateway applies allow-lists, redaction and rate and cost limits, and guardrails check inputs and outputs. Its design is provider-neutral, including open-weight and local models.
- Mask national ID numbers before the model call; cap spend per task.
**Ask a human when it matters**
- Policies define which actions need approval, such as refunds above a limit or messages to customers. The agent pauses and the approver sees what it intends to do. A kill switch can stop one agent or all of them.
- Refunds above the limit wait for a supervisor.
**Leave evidence**
- Every context request, gateway call, redaction and approval is sent to Cyclopes. Evaluation results flow back, so you can tighten a policy where an agent misbehaved. Memory writes record where each item came from.
- Why did the agent send this message? Open the trace.
### Capabilities
**Context assembly**
- Retrieves the Zeus objects, documents and memories that a task needs. Results are filtered by the permissions of the requester and of the agent, and by data class and purpose. The agent receives only that filtered bundle.
- Retrieval from ontology, documents and memory
- Filtering by person, agent, purpose and data class
- A prepared bundle, not raw database access
- What an agent has never seen, it cannot leak or misuse.
**Memory**
- Short-term, long-term and shared memory with retention rules and provenance. Each item records where it came from and who may see it. Items can be forgotten, which supports legal erasure and customer requests. Argus hosts the memory, and Monolith governs access and what gets written.
- Short-term, long-term and shared memory
- Provenance on every item
- Retention rules and erasure
- An agent that remembers everything forever is a liability.
**Governance**
- Policy by data class, purpose and region. You can say that national ID numbers never leave the country, or that customer data may be used for service but not for marketing. Policies are written as code, versioned and reviewed.
- Policy by data class, purpose and region
- Policy as code, versioned and reviewed
- Evaluated through Odin
- Data protection law is about purpose and place, not only about who.
**Agent permissions**
- Per-agent limits on tools, data, systems and spend. An agent that drafts letters cannot also issue payments. Limits are enforced through Odin, so they apply in every product the agent touches.
- Tool, data, system and spend limits
- Least privilege by default
- Enforced through Odin
- Over-permissioned agents are the most common way an AI pilot becomes an incident.
**Tool and model gateway**
- A single controlled path to tools, through MCP and similar protocols, and to language models. The design includes provider routing, fallbacks, open-weight and local models, redaction, rate limits and cost caps. The platform review places the gateway in Monolith.
- Allow-lists for tools and models
- Redaction and cost caps
- Provider-neutral, with local models in scope
- One path is a path you can watch, limit and switch off.
**Guardrails**
- Checks on inputs and outputs, defences against prompt injection and triggers for human review. No single control is claimed to be sufficient. They work together with least-privilege permissions and approval requirements.
- Input and output checks
- Prompt-injection defences
- Human-in-the-loop triggers
- Layered controls fail more gracefully than one clever filter.
**Agent registry**
- The list of every agent, with its owner, version, permissions, status and recent activity. Retiring an agent or rolling back a version is a registry action. Auditors can see in one place what automation the organization runs.
- Owner, version, purpose, permissions
- Status and kill switch
- Compatible with agents you already built (to be validated)
- You cannot govern what you cannot list.
**Approvals and kill switches**
- Define which actions need a person to approve and who may approve them. Approvals can reach people through the channels they use. A kill switch stops one agent, a class of agents, or all of them, and is enforced through Odin.
- Approval rules by action and amount
- Email and messaging channels
- Kill switch per agent or globally
- Trust grows when people can stop the system quickly.
### Context is the new access control
- In older systems, access control decided which screens a person could open. With agents, the important decision is what goes into the context: the text and data the model receives for a task. If a record is in the context, the model can repeat it, reason on it or be tricked into sending it elsewhere.
- Monolith treats context assembly as a governed step. It does not give an agent a database connection and hope for the best. It builds a bundle for the task, filtered by the person asking, the agent, the purpose and the data class. That bundle is what the model sees, and the bundle is what Cyclopes records.
- Filter by person, agent, purpose and region.
- Redact before the model call, not after.
- Record what was in the bundle.
- Keep memory separate by patient, customer or case where needed.
### Use cases across Africa
- Banks
- A bank wants a customer-service assistant. It must answer account questions but must not see full KYC files, and must not change anything without checks.
- Monolith limits the assistant to account status and recent transactions for the customer on the line. KYC files are not loaded into context. Sensitive actions, such as changing a phone number, need approval, and every call is logged.
- Compliance decides what the assistant may see and which actions require approval. A supervisor approves or rejects flagged actions.
- Telecoms
- An operator wants an agent to propose retention offers to customers who may leave. Customers have consented to some uses of their data and not others.
- Monolith restricts the agent to data covered by consent and blocks use of data outside it. It caps messages per customer and spend per campaign. Offers above a value go to a manager for approval.
- Marketing leaders set the offers and caps. The privacy officer decides which data uses are permitted.
- Agriculture
- A cooperative wants an assistant that answers farmers in their own language on planting, pests and prices. It must not invent advice or reveal other farmers' records.
- Monolith limits answers to approved agronomy sources and to the records of that farmer's cooperative. It keeps each farmer's memory separate. Questions outside its sources are routed to an extension officer.
- Agronomists choose the approved sources. Extension officers answer the questions the assistant passes on.
- Government
- A ministry wants an assistant to help officers draft responses to permit applications. The assistant may draft, but only an officer may issue. Data must stay within regional policy.
- Monolith lets the assistant read the application and the relevant rules, and write a draft. It has no permission to issue. Region policy controls which models may receive any data, including local models only where required.
- The officer reviews, edits and issues the decision. The ministry decides which data classes may leave a region, if any.
### Interfaces
- Agent registry API
- Context API
- Policy as code
- Authoring and review; evaluated through Odin.
- MCP gateway for tools
- Model gateway
- Provider-neutral.
- Approval webhooks
- Email approvals
- WhatsApp and messaging approvals
- SDK
- The lists describe target interfaces and are confirmed per release and per design partner. Nothing on this list is a claim that an integration with a named third party exists today.
### Security and sovereignty
**Least privilege**
- Agents start with no access and are granted specific tools, data and spend. Limits are enforced through Odin.
**Region and class policy**
- Policy controls which data may be sent to which model or tool. Sensitive data can be kept to local models and in-country storage.
**Memory you can erase**
- Memory has provenance and retention rules, and supports erasure. Memory is hosted on Argus inside your boundary.
**Threat model first**
- Our priorities: prompt injection, over-permissioned agents, exfiltration through tools and runaway cost. A written threat model is a launch requirement.
### What Monolith does and does not do
- Register and track agents.
- Assemble filtered context and govern memory.
- Apply policy by data class, purpose and region.
- Route calls through a controlled gateway.
- Require approvals and provide kill switches.
- Run its own login or policy engine. It evaluates through Odin.
- Physically store memory or execute agents. Argus does.
- Model the business. Zeus does.
- Claim that any single control stops prompt injection.
- Promise a specific list of supported models yet.
### Questions
- How is Monolith different from Argus?
- Monolith decides and governs. Argus stores and runs. Argus hosts the memory and executes the agents, and Monolith governs access to that memory, what gets written and what the agents may do.
- Can we stop an agent immediately?
- Kill switches are part of governance. You can stop one agent, a class of agents or all agents. Enforcement goes through Odin, so it takes effect at the next decision.
- Can we keep sensitive data from leaving the country?
- Policy by region and data class is designed to control which models and tools may receive data, including keeping it to local models. The effect depends on the models and infrastructure available in a given country.
- Which models can agents use?
- The gateway is designed to be provider-neutral, including open-weight and local models.
- How do you defend against prompt injection?
- With layers: input and output guardrails, tool allow-lists, least-privilege permissions and human approval for sensitive actions. We do not claim any single control is sufficient, and we write a threat model for each product.