# Argus

> Argus is the Boltcliq private data and cloud platform for agentic systems: deployment, sandboxes, agent desktops and Postgres, portable by design.

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

Where your agents run and where their data lives, inside your boundary. Argus is a private data and cloud platform for building and deploying agentic systems, on Postgres and AWS first and portable by design.
- Three: deployment modes: your AWS account, Boltcliq-managed single tenant, portable infrastructure
- Isolated: sandboxes designed with no default network egress and per-task lifetimes
- Replayable: agent desktop sessions recorded for review
- Standard: Postgres, Kubernetes and Terraform, to avoid lock-in
- Run the agents where your data is, not the other way round.
### Overview
- Agents need somewhere to run. They execute code, open browsers, call tools and store what they learn. If that happens on a developer laptop or in a shared cloud account with the rest of the company, a single mistake can reach far. And for banks, health systems and governments, where the data lives is a legal question as well as a technical one.
- Argus is the runtime and the data platform for the Boltcliq stack. It packages, versions, deploys and scales agents and workflows. It runs their code and tools in isolated sandboxes, and gives computer-use agents managed virtual desktops that are recorded and can be replayed. It hosts the context and memory that Monolith governs, on Postgres as the system of record, with object storage and backups.
- Argus is designed to run inside your boundary. The first target is your own AWS account, or a Boltcliq-managed single tenant if you prefer not to operate it. It is built on Kubernetes, Terraform and standard Postgres, so it can also run in local data centers and on premises. AWS is first for speed. It is not a lock. Where a customer needs in-country hosting, the design intent is a tested path there, and AWS's African footprint is checked per customer.
### Argus in one picture
- Where your agents run and where their data lives, inside your boundary. Argus is a private data and cloud platform for building and deploying agentic systems, on Postgres and AWS first and portable by design.
- A place to deploy, scale and roll back agents and workflows.
- Sandboxes and recorded desktops that keep the blast radius of a mistake small.
- Postgres-backed data and memory in the jurisdiction you choose.
- Schematic of Argus. Illustrative, not a product screenshot.
### How it works
**Package the agent or workflow**
- An agent or a Zeus workflow is packaged as a versioned release with its resources and environment settings. The release is promoted from development to staging to production. Earlier versions are kept, so you can roll back.
- Release v1.3 of the reconciliation agent to staging.
**Deploy inside your boundary**
- Choose where it runs: your own AWS account, a Boltcliq-managed single tenant, or portable infrastructure such as a local data center. The same packaging works in each.
- Run in your Cape Town region account, or in a local data center when required.
**Run in isolation**
- Code and tools execute in sandboxes with short lifetimes and no default network access. Agents that must use software with no API get a managed virtual desktop. Credentials are brokered through Odin, never typed or stored by the agent.
- The agent fills a supplier portal on a recorded desktop; the password is brokered.
**Keep the data**
- Postgres is the system of record, with pgvector for embeddings, object storage for files, backups and point-in-time recovery. Argus hosts the vector, relational and object storage that Monolith uses for memory. Data stays where the deployment mode puts it.
- Restore a database to ten minutes before a bad import.
**Scale, watch and attribute cost**
- Quotas, isolation and cost attribution apply per customer, environment, team and agent. Runtime telemetry and session recordings go to Cyclopes. If an evaluation shows a regression, you roll the release back.
- Roll back to v1.2 after an evaluation regression.
### Capabilities
**Agent deployment**
- Package, version, deploy, scale and roll back agents and workflows. Releases move through environments with review. The same mechanism runs Zeus workflows and the agents that Monolith governs.
- Versioned releases
- Promotion across environments
- Scale and rollback
- Agents change often. Deployment has to make change safe and reversible.
**Sandboxes**
- Isolated environments where code and tools run. The design target is microVM-class isolation, no default network egress and a lifetime tied to the task. If a sandboxed agent is tricked or wrong, the damage is limited to a small, short-lived space.
- Isolation target: microVM-class
- No default network egress
- Per-task lifetime and resource limits
- Sandboxes and desktops are the highest-risk surface in the platform, so they get their own threat model.
**Virtual desktops for agents**
- Managed desktop and browser machines for agents that must work in software with no API, such as a supplier portal or a government site. Sessions are recorded and can be replayed. Credentials come from Odin and are never held by the agent.
- Managed desktop and browser sessions
- Recording and replay
- Credential brokering through Odin
- Much of African business software has no API, and people already work in it by hand.
**Context and memory hosting**
- Relational, vector and object storage for the context and memory that Monolith governs. Argus hosts it, and Monolith decides who may read it and what may be written. Memory inherits the residency of the deployment.
- Relational, vector and object storage
- Governed through Monolith
- Inherits deployment residency
- Memory is customer data. It should live where the rest of that data lives.
**Postgres data platform**
- Postgres as the system of record, with pgvector, backups and point-in-time recovery. It holds the ontology early on, and anything that needs transactions.
- Postgres with pgvector
- Backups and point-in-time recovery
- Analytical store for heavy workloads
- Standard Postgres means standard skills, and no lock-in.
**Tenancy and isolation**
- Per-customer and per-environment isolation, with quotas and cost attribution. A development agent cannot touch production data. Cost can be attributed per team and agent, which supports usage-based pricing. The pricing model is not yet fixed.
- Customer and environment isolation
- Quotas
- Cost attribution per team and agent
- AI spending can grow quickly, and in dollars. It needs to be visible and capped.
**Environments and promotion**
- Development, staging and production environments for agents, workflows and data schemas. Promotion is reviewed. The environments share the same packaging, so what you tested is what you run.
- Dev, staging, production
- Reviewed promotion
- Same packaging in each
- It stops experiments from reaching customers by accident.
**Deployment modes**
- Your own AWS account (a VPC), a Boltcliq-managed single tenant, or portable infrastructure, using Kubernetes, Terraform and standard Postgres. A path to African data centers and to on-premises is part of the design. Which modes are generally available is stated honestly at each release.
- Customer-owned AWS account
- Boltcliq-managed single tenant
- Portable: local data center and on premises
- Sovereignty needs a real answer to where the data sits. Our target is for the answer to be testable.
### AWS first, portable by design
- Boltcliq wants to run where customers need us to. That includes your own AWS account, and also local data centers and on-premises infrastructure when a regulator or a contract requires it. The technical rule that makes this possible is simple: use the cloud for capacity, but build on standards.
- Argus uses Kubernetes for packaging, Terraform for infrastructure and standard Postgres for data. We use AWS to move fast. We avoid services that exist only on AWS, so that the same platform can be installed elsewhere. This is a design rule and a goal. The move to a given local data center is verified with the customer and the partner, not assumed.
- Kubernetes, Terraform and standard Postgres.
- No dependence on AWS-only services where a standard exists.
- Residency checked per customer and region.
- A tested path, not a slogan.
### Use cases across Africa
- Banks
- A bank wants to run agents and a data platform, but the central bank requires certain customer data to stay in country. The bank also wants to avoid sharing a cloud account with other firms.
- Argus runs in the bank's own AWS account, or on premises where the rule demands it. Postgres holds the system of record and agent memory in the chosen location. Sandboxes keep agent code inside the boundary.
- The bank's risk and legal teams decide where data may live. The platform team decides which agents are promoted to production.
- Telecoms
- An operator wants agents close to its own infrastructure and customer data. Moving data to a distant cloud region adds delay and raises regulatory questions.
- Argus can be deployed near operator infrastructure. The path to a local data center with a partner operator is part of the portable design. Cost attribution shows which campaign or team uses the compute.
- The CTO decides where to host and with which partner. Finance decides how costs are charged back.
- Agriculture
- Field staff collect data on phones in areas with weak or no connectivity. Records reach the head office days later, and in bursts.
- Argus provides the central platform that receives synced records into Postgres. Agents that process records run in sandboxes and read from the same store.
- Programme managers decide the sync schedule and what field staff must record. Data stewards decide when a late batch is accepted.
- Government
- A government wants services that use AI but must keep citizen data in the country and under its own control. Auditors require a full record of what automated tools did.
- Argus supports a sovereign, single-tenant deployment in the country. Agent sessions are recorded and sent to Cyclopes. Isolation and quotas keep each ministry's workloads separate.
- The ministry decides which workloads may run and under which law. Oversight bodies decide what recordings they need to see.
### Interfaces
- Deployment API and CLI
- Terraform modules
- Kubernetes-based packaging
- Postgres wire protocol
- Standard Postgres, with pgvector.
- S3-compatible object storage
- SDKs
- Workflow runtime for Zeus
- Internal API.
- Memory hosting for Monolith
- Internal API.
- Local data center and on-premises targets
- Edge sync for intermittent links
- 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
**Highest-risk surface**
- Agent sandboxes and desktops get their own threat model: egress control, credential brokering through Odin, session recording and strict limits.
**Residency you can test**
- AWS first, portable by design. The intent is that "your data never leaves your jurisdiction" is a tested feature, not a slogan.
**Isolation and quotas**
- Per-customer and per-environment isolation, with resource and time limits for every sandbox.
**Recorded sessions**
- Desktop sessions are recorded and sent to Cyclopes, so what an agent did can be replayed.
### What Argus does and does not do
- Deploy, run, scale and roll back agents and workflows.
- Isolate execution in sandboxes and desktops.
- Store data and memory on Postgres and object storage.
- Provide tenancy, quotas and cost attribution.
- Run inside your AWS account, as managed single tenant, or on portable infrastructure.
- Decide what agents may do. Monolith and Odin do.
- Authenticate anyone. Odin does.
- Define business meaning. Zeus does.
- Guarantee African in-country hosting yet. AWS's African footprint is limited and is verified per customer.
- Lock you in. Standard Postgres, Kubernetes and Terraform are the design rule.
### Questions
- Does our data have to be on AWS?
- No. AWS is the first target. Argus is designed to be portable to local data centers and on premises.
- Which African regions can you use?
- It depends on the current footprint of the cloud providers and on local partners. AWS has a limited presence in Africa, and we verify latency and residency per customer before any commitment.
- What is a sandbox and why does it matter?
- A sandbox is an isolated environment where code and tools run, with limited network access and a short lifetime. If an agent is mistaken or tricked, the damage stays inside a small, short-lived space.
- What are virtual desktops for agents?
- Managed desktop or browser machines for agents that must operate software with no API. Sessions are recorded and can be replayed, and passwords are brokered by Odin rather than typed by the agent.
- Do we need Kubernetes expertise?
- Not if you choose Boltcliq-managed single tenant, where we operate it. If you run it in your own account or on premises, your team or a partner needs some platform skills.