The Architecture Behind
Agentic Automation
A model-agnostic agent runtime layered on a governed data intelligence stack — connected to your systems, auditable end to end, and deployable in your own cloud or on your own hardware.
Six Layers, One Execution Path
Each layer has a distinct responsibility and a distinct failure mode. Separating them is what lets the platform stay flexible at the model layer while staying strict at the governance layer.
Interface Layer
Where people and systems talk to the platform.
Conversational workspace, dashboards, scheduled runs, inbound webhooks and REST APIs. Every entry point resolves to the same authorised execution path, so a request from chat and a request from an API carry identical permissions and audit behaviour.
Agent Orchestration Layer
Decides what work happens, in what order, and who signs it off.
Stateful agent graphs with typed tool contracts, branching, retries with backoff, timeouts, compensation steps and approval gates. Long-running work is durable — a run survives restarts and resumes from its last committed step.
Reasoning & Model Layer
The language models that read, reason and draft.
Task-class routing across hosted and open-weight models, structured-output enforcement through schemas, fallback chains, prompt versioning and offline evaluation against fixture sets before a prompt or model change ships.
Data Intelligence Layer
Turns raw sources into modelled, queryable, explainable data.
Schema inference, document parsing and OCR, embedding and retrieval indexes, transformation pipelines, a governed semantic layer for metric definitions, and forecasting and anomaly routines that run against curated models rather than raw tables.
Connector Layer
Reads from and writes back to your existing systems.
Credential vaulting, incremental and change-data capture, schema-drift tolerance, rate-limit aware scheduling and idempotent writes so a retried action never duplicates a record in the target system.
Governance & Runtime
The controls that make automation safe to run in production.
Tenant isolation, role-based access with row and column rules, lineage, PII detection and redaction, immutable run traces, and deployment topology choices that determine where data is processed and retained.
What Happens Inside A Run
An agent run is a durable, replayable transaction — not a single model call. Each step is recorded, bounded by the tools the agent was granted, and reversible where the target system allows it.
Trigger
A schedule, webhook, inbound document, database change or human request starts a run. Every run gets an identifier that follows it end to end.
Context Assembly
The agent pulls only the context it is entitled to: retrieved documents, semantic-layer definitions, prior run state and the caller's permission scope.
Plan
The model proposes a sequence of tool calls. The plan is bounded by the tools the agent is registered for — it cannot invent capability it was not granted.
Tool Execution
Tools are deterministic, typed functions: query, extract, transform, call an API, write a record. Inputs and outputs are validated against schemas on both sides.
Validation & Approval
Rule checks, confidence thresholds and reconciliation run before anything is committed. Cases that fall outside policy escalate to a person with the full context attached.
Action & Audit
The action is written back idempotently and the complete trace — inputs, model, prompt version, tool calls, decisions, approver — is stored for replay and review.
LLM-Agnostic By Design
Models are a replaceable component, not the product. The platform treats them as interchangeable reasoning engines behind stable contracts, so a provider change is a configuration change.
Task-Class Routing
Extraction, reasoning, SQL and code generation, and summarisation are routed independently. The model that reads a scanned invoice does not have to be the model that plans a workflow.
Hosted And Open-Weight
Run against hosted providers such as OpenAI and Anthropic, or open-weight families such as LLaMA hosted inside your own environment where data cannot leave the boundary.
Structured Output
Every model call that feeds an action returns against a declared schema. Malformed or out-of-schema responses are rejected and retried rather than passed downstream.
Prompt Versioning
Prompts, tool definitions and routing rules are versioned artefacts. Runs record the exact version used, so behaviour changes are attributable and reversible.
Evaluation Harness
Prompt and model changes are scored against held-out fixture sets before release, and sampled runs are re-scored in production to catch drift.
Fallback Chains
Provider outages, rate limits and timeouts fail over to a configured alternative. A degraded model layer slows a workflow, it does not stop it.
From Raw Source To Committed Action
Agents are only as good as the data beneath them. The stack turns files, documents and operational systems into modelled, explainable data that automation can act on safely.
Ingestion
Batch, incremental and event-driven intake
- Files & Spreadsheets
- PDF & Scanned Documents
- Operational Databases
- Warehouses & Lakes
- REST APIs & Events
Understanding
Structure recovered from unstructured input
- Schema Inference
- Layout-Aware Parsing
- OCR & Handwriting
- Entity Extraction
- Embedding & Retrieval
Modelling
One definition per metric, traceable to source
- Cleaning & Normalisation
- Entity Resolution
- Joins & Aggregation
- Semantic Layer Metrics
- Lineage Capture
Analysis
Methods selected against the shape of your data
- Statistical & ML Forecasting
- Anomaly Detection
- Cohort & Trend Analysis
- Scenario Modelling
- Root-Cause Drilldown
Delivery
Insight leaves the platform as an action
- Narrative Summaries
- Generated Visualisations
- Scheduled Reports
- Alerts & Triggers
- Write-Back To Systems
Built To Read And Write Back
Automation that can only read is a report. The connector layer is designed for two-way traffic — pulling context in and committing work back into the system of record.
Breadth
180+ integrations spanning relational databases, warehouses, object storage, ERP and CRM systems, ticketing, messaging, e-mail and internal HTTP services.
Authentication
OAuth, API key, service account and mTLS handling with credentials held in an encrypted vault, scoped per connection and never exposed to the model layer.
Sync Semantics
Full loads, incremental watermarks and change-data capture, with schema-drift tolerance so an added or renamed column does not break a downstream pipeline.
Event Triggers
Webhooks and change events start agent runs directly, so automation reacts to what happened in the source system instead of polling on a fixed schedule.
Write-Back
Agents complete work inside the system of record — posting entries, updating records, filing tickets — using idempotency keys so retries never double-apply.
Custom Connectors
An SDK exposes the same connector contract used internally, so bespoke and legacy systems become first-class sources and targets rather than manual steps.
Designed To Be Inspected
Regulated and public sector buyers evaluate this layer first. It is built so security teams can verify behaviour directly rather than take a description on trust.
Access Control
Role-based permissions extend to row and column level. Agents inherit the scope of the identity that invoked them and cannot read beyond it.
Tenant Isolation
Data, indexes, credentials and run history are isolated per tenant, with separate encryption contexts and no shared retrieval space between customers.
Encryption
Encrypted in transit and at rest across storage, vaults and indexes, with key rotation handled by the platform rather than by application code.
PII Handling
Sensitive fields can be detected, masked or redacted before they reach a model, and policies can block specific classes of data from leaving the environment entirely.
Lineage & Audit
Every figure traces back to its source records, and every agent run stores an immutable trace of inputs, decisions, tool calls and approvals for replay.
Guardrails
Policy checks, confidence thresholds and blast-radius limits sit between a model's proposal and any irreversible action, with human approval configurable per step.
Runs Where Your Data Is Allowed To Live
The same platform, packaged for different constraints — managed, inside your cloud account, or fully disconnected — with API access at every level.
Managed Cloud
Fully hosted and operated by Mimasa AI, with configurable data residency for teams that need processing to stay within a specified region.
Private VPC
Deployed inside your own cloud account so data planes, storage and indexes remain within your network perimeter and existing security controls.
On-Premise
Containerised deployment for air-gapped and regulated environments, paired with open-weight models hosted locally when external inference is not permitted.
APIs & SDK
Everything available in the interface is reachable through the API — trigger runs, register tools, query the semantic layer and stream results into your own products.
Embedded Workflows
Agents can be invoked from existing orchestrators, internal portals and messaging tools, so automation lands inside current processes instead of beside them.
Observability
Run metrics, latency, failure classes and approval rates are exportable to your existing monitoring stack alongside structured logs and traces.
Mimasa AI can be deployed across cloud, private-cloud and enterprise infrastructure environments based on an organisation's security and operational requirements. Through the Cisco ISV partnership, enterprises and Cisco System Integrators can also deploy AI-driven workflows and data intelligence capabilities on trusted Cisco infrastructure.
Questions Architects Ask First
How does the platform decide which model to use?
Routing is configured per task class rather than per user. Extraction, reasoning, query generation and summarisation each map to a model and a fallback chain, and the mapping is versioned so any change is attributable. Teams with residency or procurement constraints can pin specific task classes to specific providers or to open-weight models hosted inside their own environment.
How is hallucination risk controlled?
Models never produce final numbers directly. Figures come from queries against the governed semantic layer, and model output that feeds an action must satisfy a declared schema plus rule and threshold checks before it is committed. Anything outside policy is escalated to a person with the underlying evidence attached, and every run keeps a replayable trace.
Where does our data reside and who can see it?
Deployment topology determines residency: managed cloud with a configured region, a private VPC inside your own cloud account, or on-premise for air-gapped environments. Access is enforced by role-based permissions down to row and column level, credentials are vaulted separately from the model layer, and tenant data and retrieval indexes are isolated.
How do agents integrate with our existing systems?
Through the connector layer, which handles authentication, incremental sync and idempotent write-back to more than 180 systems including databases, warehouses, ERP, CRM, ticketing and internal HTTP services. Agents can also be triggered by webhooks and change events, so automation reacts to source-system activity rather than polling.
Can we extend the platform with our own tools?
Yes. Tools are typed function contracts, and an SDK exposes the same interface used internally. Custom connectors, private APIs and in-house services can be registered as first-class tools with their own schemas, permissions and approval requirements, and they participate in the same audit trail as built-in capabilities.
Review The Architecture With Our Engineers
Bring your security questionnaire, your integration list and your constraints. We will walk through the runtime, the data flow and the deployment topology that fits your environment.
See How This Architecture Supports The Mimasa Operating Model
How The Platform Is Put Together
Mimasa AI is built as a layered system rather than a single application, because the demands placed on each layer are genuinely different. Connectivity has to be tolerant of unreliable source systems and changing schemas. Storage and modelling have to be fast and reproducible. The reasoning layer has to be flexible enough to swap models as the market moves. Governance has to be uncompromising. Bundling these into one monolith is how most platforms end up strong in one dimension and weak in the rest.
At the base sits the connector layer, responsible for authenticating to source systems, pulling data incrementally, and absorbing schema drift without breaking downstream work. It is also the layer that writes results back, which is the part most analytics tools never attempt. Write-back is treated as a transactional concern: actions carry idempotency keys, retries are safe, and every committed change is attributable to the run that produced it.
Above it, the modelling layer reconciles identifiers across systems and holds metric definitions in one place, with lineage so any figure can be traced back to the records behind it. This matters more in an agentic system than in a reporting one, because an agent that acts on an ambiguous metric does not simply produce a misleading chart — it takes a wrong action in a live system.
The reasoning layer applies language models narrowly and behind stable contracts. Models translate questions into queries against curated definitions, extract structure from documents, plan sequences of tool calls, and draft outputs. They do not invent numbers or roam across raw tables unsupervised, and any output that feeds an action must satisfy a declared schema before it is accepted. Because the contracts are stable, moving between hosted providers and open-weight models hosted inside a customer environment is a routing decision rather than a rebuild.
The orchestration layer turns conclusions into work. Agents observe a trigger, gather the context they are entitled to, evaluate it against rules you define, and either complete the task in the target system or escalate to a person with everything already assembled. Approvals, thresholds and human checkpoints are configuration, not code, which means the boundary between what is automated and what stays human can move as confidence grows — usually starting with full review and narrowing to exceptions over time.
Security and governance run vertically through all of it. Role-based permissions with row and column level rules, credentials vaulted away from the model layer, PII detection and redaction before inference, encryption in transit and at rest, immutable run traces, and deployment options that keep data within a specified region or entirely inside your own infrastructure. For regulated and public sector customers this layer is typically evaluated before anything else, and it is designed to be inspected rather than described.