Every chatbot, agent, voice agent and workflow we build runs on the same four layers: Know, Reason, Reach and Control. It is how we deliver, not a product you sign up for. Each build is deployed into accounts in your name and shaped around your data, channels and rules.
Our delivery architecture, not a self-serve product.
Not a SaaS
No sign-up or trial
No shared tenant
Accounts in your name
The engine
Four layers, one system
Scroll to separate the layers, see them flatten into the diagram, and lift back into a stack. Each row links to what that layer does.
Four stacked layers of the Agent Engine (Know, Reason, Reach and Control) separate, turn to face you and flatten into the labelled diagram rows, then lift back into a stack.
01 · KnowBefore anything runs, your sources are ingested, versioned and indexed, and live systems are connected for lookups.
02 · ReasonA message arrives. The router classifies it, the specialist step retrieves evidence and decides what to say or which tool to propose.
03 · ReachThe reply or the action goes out through the channel adapter and your system’s API, with an idempotency key on every write.
04 · ControlEvery step is checked and logged; consequential actions wait for approval and uncertain answers go to a person.
05 · ControlTranscripts and failures feed the evaluation set, which gates the next change.
Know → Reason → Reach → Control
Four layers, told in the order a build needs them
Each layer has a job, the mechanisms that do it, and a deeper page that explains the choices and their alternatives.
Layer 01 · Knowledge and data
Know: your knowledge, indexed with its provenance
Everything the system may say starts here. Documents, policies, catalogues and records are ingested with their source, version and visibility, and kept current, so an answer can always point back to where it came from.
Content is split by heading into chunks that carry the source URL, version, topic and who may see it. Drafts and internal pages stay out unless the build is for internal use.
Hybrid retrieval
Keyword search and embedding search run together and their rankings are fused. Exact terms such as plan names and SKUs, and questions phrased in a customer’s own words, fail in different ways; using both covers each other’s gaps.
Supersede, never append
A new version of a document replaces its old chunks instead of sitting beside them, so the system cannot cite last year’s policy next to this year’s.
Live data stays in its system
Order status, bookings and stock are fetched through the owning system’s API at the moment of the question, not copied into the index where they would go stale.
Layer 02 · Routing and tools
Reason: a state machine around the model
The model reasons, but inside a flow we can test. A router decides what kind of request this is, a specialist step handles it with the evidence from Know, and tools are proposed only from an allowlist.
Greetings, requests for a person, pricing questions and injection attempts follow fixed paths that need no model call. The model handles what genuinely needs judgement.
Tools from an allowlist
Every tool has a typed schema, a read or write scope and a rule for whether it needs approval. The model may propose a call; the runtime decides whether it runs.
A model per step, behind one interface
Providers from our build stack (OpenAI, Anthropic, Google Gemini, Mistral AI, or open-weight models such as Meta’s Llama) are chosen per step on quality, speed and cost, and can be swapped without rewriting the flow.
Evaluation gates every change
Each build has its own evaluation set. A prompt, tool or model change runs against it before release, and a regression blocks the release.
Layer 03 · Channels and integrations
Reach: one event format behind every channel
Website chat, WhatsApp, phone calls, email and your internal tools connect through adapters that translate each channel into one internal event. The logic is written once and every channel gets it.
Each adapter handles its channel’s rules, such as WhatsApp’s customer-service window and approved templates, turn-taking on a call or threading in email, and emits the same event to the layers below.
Your systems through their APIs
CRMs, helpdesks, calendars and databases connect through their own APIs with a scoped credential each, in your accounts. Inbound webhooks are signature-checked before anything acts on them.
Writes that are safe to retry
Every write carries an idempotency key, so a webhook delivered twice or a retried call never creates a second lead, ticket or booking.
Visual workflows where a team wants them
n8n, Make or Zapier when your team wants to see and edit the flow; TypeScript or Python on Cloudflare Workers when reliability or running cost matters more.
Layer 04 · Guardrails and operations
Control: guardrails, people and a record of everything
The layer that keeps a system safe in production: what it may say and do, when a person takes over, and the logs that show afterwards exactly what happened and why.
User messages and retrieved text are scanned for injected instructions. Retrieved text is treated as data, never as instructions, and flagged passages are dropped.
Approvals and handoff
Consequential actions wait for a person. Low confidence, a request for a human or a sensitive topic hands over with the transcript and context attached, so nobody starts cold.
Checks before anything is sent
Replies are validated on the way out: prices only from published sources, links only to allowed pages, personal data such as card or ID numbers redacted before storage or a model call.
Operations you can read
An outbox retries failed sends with backoff, dead letters wait for a manual replay, admin actions go to an audit log and alerts go to a named owner, not to a shared inbox.
Every build shares the same four layers and the defaults above. What changes per project is everything that carries your business: the sources, the intents and tools, the channels, the handoff rules and the evaluation set.
Defaults
Twelve engineering defaults in every build
These ship unless you decide otherwise in writing. They are the reason a fast first version is still a safe one.
01
Cite, or say you are not sure
Grounded answers show their sources. When nothing relevant is retrieved, the system says so instead of improvising.
02
Uncertain goes to a person
Low confidence, a complaint or a request for a human hands over with the transcript, the detected intent and the record it concerns.
03
The system says it is an AI
Chat and voice agents disclose that they are AI at the start, and a person is always one request away.
04
Accounts in your name
Model, messaging, telephony and hosting accounts are registered to your business. You hold the keys and pay the providers directly.
05
One scoped key per integration
Each connection gets the narrowest access its job needs, recorded so it can be rotated or revoked on its own.
06
Approval before consequential actions
Refunds, outbound sends, deletions and anything touching money wait for a named person to approve.
07
Retries that never duplicate
Idempotency keys on every write, exponential backoff on failures, a dead-letter list and manual replay.
08
An evaluation set per build
Questions or cases from your own data, scored before launch and re-run before every change ships.
09
Personal data redacted early
Card numbers, government IDs and passwords are removed before anything is stored or sent to a model.
10
Retention you decide
Transcripts and logs are deleted on a schedule you set, and a visitor can reset or delete a conversation.
11
An audit log of changes
Admin actions and automated writes are recorded with who or what made them and when.
12
No lock-in to one model
Model calls sit behind one interface, so moving to another provider is a configuration change and an evaluation run.
Configuration
What a build looks like as configuration
An illustrative build configuration for a store-support assistant. Every value here is Sample data; a real file is written for your sources, tools and rules during the build.
engine.config.yamlSample data
# engine.config.yaml (Sample data: illustrative, not a client file)
assistant: store-support
disclosure: "I am an AI assistant for the store. Ask for a person at any time."
know:
sources:
- id: returns-policy # document; new versions supersede old chunks
supersede: true
- id: product-catalog # synced on a schedule
sync: daily
retrieval: { mode: hybrid, fuse: rank-fusion, top_k: 6, cite: required }
reason:
router: [greeting, order_status, returns, product_fit, human, other]
tools:
- name: get_order_status
scope: read
requires: [order_id, checkout_email]
- name: open_return_request
scope: write
approval: none # policy-eligible returns only
- name: issue_refund
scope: write
approval: human
reach:
channels: [web_widget, whatsapp]
writes: { idempotency: true, retries: 6, backoff: exponential }
control:
handoff_when: [low_confidence, asked_for_human, complaint, payment_dispute]
redact: [card_number, government_id, password]
transcript_retention_days: 30
release_gate: { eval_set: store-support, must_pass: true }
Deployment
Three ways to run it
Data residency depends on each provider’s regions and is checked per project before anything is promised.
The default. Hosting such as Cloudflare, Supabase or Vercel and model APIs such as OpenAI, Anthropic or Google Gemini are registered to your business; we work through delegated access that you can remove.
Fits: Most chatbots, agents and automations.
Self-hosted open-weight models
Open-weight models from Hugging Face, such as Llama or Mistral, run on infrastructure you control, so prompts and documents never reach a third-party model API. The trade-off is more operations work and a model chosen by testing on your tasks.
Fits: Sensitive documents and steady, predictable volume.
On-premise
Every layer runs inside your own network, with no external processing. It is an Enterprise scope, priced per project after a technical review of your environment.
Fits: Environments that rule out any external processing.
Services
How the layers map to the six services
Every service uses all four layers. What changes is where the work concentrates.
You can check these yourself. We describe what they do and how they are tested; we publish numbers only with their method and date.
In-house build
The assistant on this site
Answers from this website’s published pages with hybrid retrieval and citations, offers a person when it is not confident, redacts card and ID numbers before storage, keeps transcripts for 30 days under a hashed session id, and lets you reset or delete a chat. Releases are checked against a 150-question evaluation set; results are published only with their method and date.
The same submission sent twice creates one lead and one reference number. Notification emails go through an outbox that retries with backoff, and the admin that reads the leads sits behind Cloudflare Access with an audit log.
Not a SaaS: there is no sign-up, sign-in, free trial or self-serve dashboard.
Not a shared tenant: each build runs in its own accounts with its own data stores.
Not a black box: the deliverables made for you, including configuration, prompts and documentation, are yours once paid for.
No uptime percentage: we describe what we monitor, and a custom SLA is available for Enterprise scope.
Not certified: our practices are security-first and HIPAA-aware where it applies; we hold no SOC 2 or ISO certification.
FAQ
Questions about the Agent Engine
Is the Agent Engine a product we can sign up for?
No. The Agent Engine is how we build, not something you log in to: there is no sign-up, trial or dashboard. Each engagement deploys the four layers into accounts in your name and configures them around your channels, data and rules.
If the engine is shared across builds, what is actually custom in ours?
The layers and the defaults are shared: ingestion, routing, channel adapters, guardrails and logging. Everything that carries your business is built for you: the sources and how they are split, the intents and tools, the channel setup, the handoff rules, the evaluation set and its thresholds. The shared foundation is why a first working version typically lands in 5–14 days.
Who owns what is built on the engine once the project is paid for?
You own the deliverables made for you once paid in full: configurations, knowledge bases, workflows, prompts, integration code and documentation. The engine and our other pre-existing tools stay ours, and you get a permanent, royalty-free licence to use and modify them as part of your system, including by another developer. Section 7 of our terms sets this out.
Can we choose or change the language model behind our build?
Yes. Model calls go through one interface, so the provider is a configuration choice per step: OpenAI, Anthropic, Google Gemini, Mistral AI or an open-weight model. We choose by testing on your evaluation set for quality, speed and cost, and a later switch is a re-run of that set rather than a rebuild.
Can the engine run without sending our data to a third-party model API?
Yes, by running open-weight models on infrastructure you control, or on-premise as an Enterprise scope. The trade-offs are more operations work and a model chosen by testing on your own tasks. Where a provider is used, residency depends on its regions, which we check per project.
Do you publish an uptime figure for systems built on the engine?
No. We describe what we monitor instead: failed runs, retries, dead letters, handoff rates and provider errors, each alerting a named owner. Enterprise engagements can agree a custom SLA in the contract.
How does the engine stop instructions hidden in a document or web page?
Retrieved text is treated as data, never as instructions. Sources are scanned for injected commands when they are indexed and again when they are retrieved, flagged passages are dropped, and tools sit behind an allowlist with approval for consequential actions, so even a missed injection has very little it can do.
What happens to our system if we stop working with MiniAI Labs?
It keeps running. It lives in accounts in your name, you hold admin control, and our access is removed at handover or whenever you ask. You can run it yourselves, bring in another developer under the licence in our terms, or ask us for quoted changes later.
