Talk →
auramind · Our AI agent platform

Our product, our proof.

An AI agent platform. Multi-tenant, in production, and shipping every month since January 2026.

At a glance
Status● In production
Live atauramind.tech→
ShippingEvery month since Jan 2026
AgentsAuthored, scheduled, delegating
RunsTraced end to end, bounded
CodeSandboxed, egress-proxied
RetrievalTag-based RBAC, cited
ToolsNative connectors + MCP
§ 01
What it is

An agent platform, not a chat window.

auramind is an AI agent platform built for teams that need to put a real LLM-backed system in front of real users — not a notebook demo, not a chatbot wired to a single API, but a multi-tenant product where an agent can be defined, given tools, put on a schedule, and held to a budget.

It started as retrieval: ask a question, get an answer cited to your own documents. That still works, and it is still what most buyers picture when they say they want AI on their data. But answering a question is the smallest thing a model can do for you. The platform now takes a described job — read this week's merged pull requests, group them into features and fixes, publish the page — and runs it. Think, act, observe, repeat, until the work is done or the budget says stop.

We built auramind because we needed an AI platform Arc10 actually ran on. Today it is that system, it is live, and it is the proof point we point at when a buyer asks whether we have shipped AI to production.

§ 02
How it's wired

Job → agent → loop → tools → trace.

A request arrives as a job, not as a prompt. The orchestrator picks an agent; the agent runs a loop; every step in that loop is either a model call routed across providers or a tool call into a registry whose privileges are graded by who owns the tool. Retrieval is one of those tools. So is code execution — which happens inside a container that is a separate trust domain from the application, with no network of its own. The loop is bounded: fan-out caps, depth limits, token and wall-clock ceilings, and guards that stop an agent repeating a call that already came back the same. Every model call, tool call and sub-agent lands in a run trace you can read afterwards.

The walkthrough on the call is the inspection — pick the part you want to see.

§ 03
The components

Six components. Each independently load-bearing.

01

Agent runtime and orchestration

An agent is a definition — a prompt, a model, and the tools it is allowed to touch. The orchestrator runs it as a loop, and can delegate to other agents as though they were tools.

Why it matters

A hard-coded chain answers one shape of question; anything else means another chain. Making the agent a record rather than a code path is what turns one workflow into a platform, and delegation is what lets a long job be composed out of short ones.

How it's built

Agents are authored at organisation or personal scope against a tool registry with graded privileges. A run can be triggered from chat, from the API, or on a schedule described in plain language and confirmed before it is set.

02

Run traces and bounded runs

Every model call, tool call and sub-agent in a run is recorded as a tree you can read after the fact, with the wall time and token cost of each step.

Why it matters

An agent that fails silently is worse than no agent. When a run goes wrong the first question is which step went wrong, and a system that cannot answer it cannot be operated. It is also the difference between a demo and something you are willing to leave on a schedule.

How it's built

Runs carry fan-out caps, depth limits, and token and wall-clock ceilings, so a bad loop costs a bounded amount instead of an unbounded one. An agent that calls the same tool with the same arguments and gets the same answer back is stopped and told to change course; a run that stops making progress ends rather than grinding to its ceiling.

03

Sandboxed code execution

When the model writes code — to reshape a spreadsheet, do the arithmetic, render a document — that code runs in an isolated container, and what it produces comes back as a file.

Why it matters

Models are unreliable at arithmetic and good at writing the program that does it correctly. But a model that can execute code can reach your file system and your network unless something stops it. The sandbox is that something, and the reason the capability can be wide instead of narrow.

How it's built

A separate image and a separate trust domain from the application, with no network of its own. Every connection it attempts goes through a proxy that decides per connection and logs the outcome. Files it produces come back as artifacts you can open, download, or have emailed.

04

Tag-based RBAC and cited retrieval

Documents carry tags; a user's retrieval is scoped to the tags their account has been granted. Answers cite the sources they came from.

Why it matters

Most RAG systems do access control at the wrong layer. Filtering after retrieval is too late — the model has already seen the data. Enforcement belongs at the retrieval boundary, and tenancy belongs below that.

How it's built

Tags are first-class: attached at upload, queried at retrieval, enforced before any context reaches the model. Embeddings are partitioned per tenant, and a query that cannot prove which organisation it belongs to is rejected rather than broadened.

05

Multi-provider routing with failover

Models and providers are records an administrator edits, not constants in the source. Requests route across them, and one provider going down does not end a conversation.

Why it matters

Single-provider systems are brittle. Outages, rate limits, and model deprecations all arrive as production incidents. Routing across providers makes the system survivable — and makes model choice configuration rather than a deploy.

How it's built

A circuit breaker per model, active health probing, and automatic failover down a candidate chain. An auto mode reads what a request actually needs and picks the model for it, instead of making the user choose fast or thinking every time.

06

Connectors and MCP

Agents reach outside the platform through first-party connectors — GitHub, Gmail, Notion, Slack, HubSpot, Linear — and through any MCP server you point them at.

Why it matters

An agent that can only read your documents can only tell you things. The work happens in the systems you already run, and an agent that cannot open the pull request or send the email is a research assistant rather than a colleague. MCP means the list is not ours to gatekeep.

How it's built

First-party connectors handle OAuth and token refresh per organisation, with third-party credentials encrypted at rest. MCP servers are discovered and their tools composed into the same registry the first-party tools live in, so an agent's tool list does not care where a tool came from.

§ 04
The decisions, and why

A few choices that aren't obvious until you've lived with the alternative.

01

Multi-provider over single-provider

The fastest way to ship an LLM product is to call one vendor's API directly and stop thinking about it. We did not do that. The reason: every production AI system we have shipped or watched ship has eventually had a provider-side outage that turned into a customer-facing one. Routing across providers is operational hygiene, not vendor agnosticism for its own sake. The cost is a routing layer that has to know the differences between providers — token limits, streaming behaviour, tool-calling support, rate-limit semantics. We pay that cost on purpose.

02

A sandbox that is a separate trust domain

There is a class of agent tooling that hands the model unrestricted code execution and lets it work out how to answer. That is fine in a demo. It is not a production posture — the model can, and eventually will, write code that touches the file system, makes network calls, or shells out in ways the operator did not intend. The tempting fix is to narrow the tool until it cannot do harm, but a narrow tool only moves the ceiling and you pay for it in every job the tool cannot do. We made the boundary real instead: a separate image, a separate trust domain, no network of its own, and a proxy that decides every connection out and writes down what it decided.

03

Bounds and traces before capability

Agent runs were bounded and recorded before they were allowed to do anything interesting. That ordering was deliberate and it cost us weeks of looking slower than we were. An unbounded loop is a bill with no ceiling and a failure with no explanation, and both of those end up as somebody's incident at 3am. Depth limits, fan-out caps, token and wall-clock ceilings, and a readable trace of every call are what make it reasonable to hand an agent a schedule and go home. Capability without a bound is a demo.

§ 05
How it ships

Every month since January 2026.

auramind has shipped in every month it has existed. Five services, versioned independently off conventional commits, each with a changelog generated from the history rather than written from memory. The quarters below are the summary; the record is in Git.

2026 · Q1

Chat grounded in your own documents, cited to the source and streamed as it is written. Then role-based access control, an admin panel, API keys, and a second model provider behind the first so one provider failing could not end a conversation.

2026 · Q2

DocRAG became auramind. Organisations, invitations, seats and entitlements turned a single-tenant product into a multi-tenant one. Providers became records rather than constants, with circuit breakers and health probing behind them. Then agents: definitions, an orchestrator that delegates, run traces, and bounded runs.

2026 · Q3

Subscriptions, seats, credits and overage through Stripe. Scheduled runs described in chat and confirmed before they are set. A router that picks the model per request. Sandboxed code execution behind an egress proxy, and an agent builder that drafts an agent, test-runs it, and revises it before anything is created.

We don't show you a roadmap on a slide. We show you the commits.

§ 06
The bridge

The team that ships ours is the team that ships yours.

auramind exists because Arc10 needed an AI platform Arc10 itself ran on. The team that designed it, built it, and runs it is the same senior engineering bench we put on client engagements.

If the architecture above looks like the kind of thing you'd want shipped into your product, the path is short — we're already that team. We've already made the production-AI mistakes you would otherwise pay to learn. Hire us once and you skip the prototype-to-production cliff that ends most AI initiatives.

Talk

Talk to a senior engineer.

We'll walk you through auramind's architecture on the call — yours, not ours. Pick the part you want to inspect.

What to expect
Emailhello@arc10.io
First replyWithin one business day
First call30 minutes with a senior engineer
No salesEngineering questions, engineering answers