Start building with Alchemist
Start building with Alchemist
The core concepts behind the platform — how an agent is defined, how it acts, how it remembers, and how recorded actions support attribution while the enterprise retains accountability. For a plain-language overview start with What is Olbrain; for terms, see the glossary. For APIs, SDKs and webhooks, see the developer docs.
Olbrain is The Agent OS for building, running and governing agent systems that work together. Specialized agent systems work toward business-wide goals and constraints, with relevant shared context, clear responsibilities and handoffs, and common governance. Each deployment defines what context may be shared, who owns each decision, when work passes between systems, and where human approval is required.
These connections are designed and validated for each deployment. A shared platform alone does not establish coordination, complete action capture or enterprise-wide learning. Workflow design is configurable; integrations, shared context, controls and cross-system behavior require engineering and validation within the agreed scope.
Hypothetical example: a proposed price reduction connects sales, finance, operations and customer service. Sales supplies the demand assumption; finance tests margin constraints; operations checks capacity; customer service reviews the customer promise. Named owners resolve conflicts and approve the decision before downstream action. This illustrates a workflow to configure and validate, not a shipped autonomous pricing capability or a customer result.
The aim is coordinated business outcomes: specialists carry out their responsibilities while handoffs and controls keep the wider business objective in view.
An agent on Olbrain is a continuous actor with a defined purpose that can converse, run workflows, call tools, and act on triggers. Olbrain supports five agent types on one orchestration layer: Concierge (conversational), Operator (workflow), Analyst (research), Orchestrator (coordinates a team), and Designate (role-holding — humans supervise). Three runtimes — conversational, workflow, and research — are live.
An agent is defined by its brain — identity, tools, knowledge, channels, and guardrails — which compiles into a deployable system prompt and runtime configuration. The brain is generated from a BRD (a business-requirements document) that the platform produces during discovery, and it is versioned and immutable on publish, so the published configuration can be traced; this does not guarantee identical model behavior or outputs.
Work is expressed as workflows: directed graphs built from 37+ typed step executors — document AI, reasoning, integration, data ops, control flow, human gates, and outputs. Steps fan out per item and aggregate once. Workflows are bound to a specific agent at both definition and run time, so every audit event is attributable to that agent.
Agents reach external systems through tools, implemented as MCP tool servers, and through connectors. MCP has been used for external tool calls in production. Tools are how an agent does things in the world — query a system, file a record, trigger a downstream process — recorded calls associated with the acting agent.
Knowledge grounds an agent on enterprise data — documents and systems — so its answers and actions are grounded in your information. Knowledge is part of the agent brain and is governed under the same identity and audit model as everything else the agent does.
Agents and workflows start from triggers: a conversation, another agent, an external event, or a schedule. Triggers let agents act proactively and react to the systems around them, not only when a person prompts them.
External identity governs access; self-identity concerns the actor to which a mandate and record belong. The identity-bound, signed, append-only record is live. Full cryptographic exclusivity and narrative-continuity enforcement remains in development. The enterprise retains accountability. See the capability record.
Persistent memory is provided by the Context Service: append-only, judge-gated memory scoped global → agent → session. At runtime an agent’s state — context, memory and history — is compressed into a CS-packet that travels with each query to the model. The CS-packet carries runtime context; it is not an identity construct or a billing unit. See current pricing.
The identity-bound, signed, append-only record and PII-free receipts support attribution of recorded actions. This does not by itself establish complete action capture. Detected PII is tokenized (deterministic encryption, Cloud-KMS envelope keys) before any payload reaches a language model. Replay and audit evidence must be assessed against the recorded data and supported action paths for the specific deployment. Complete replay of every action or external side effect is not claimed.
Every agent is governed from a single control plane, Olbrain Noesis (noesis.olbrain.com): observability, policy enforcement, and lifecycle management, with recorded actions associated with named agent identities. Agents run on Olbrain’s cloud — India-hosted (Google Cloud, Mumbai), DPDP-aligned, with tenant isolation and per-tenant key management — so no infrastructure is required from you. Security status is on the Trust page.