Agents and runtimes
This page covers what an agent is in mDecide, where it runs, what it is allowed to touch, and — the part that matters most in an evaluation — how authority is divided between the people and the agents working a decision together.
Definitions and instances
mDecide separates specifications from running things consistently, and the same split recurs three times.
| Specification | Running instance |
|---|---|
| Agent definition — what an agent does, its constraints, which tools it may use, which foundation model backs it | Agent — one instance of that definition, scoped to one span of work, holding its own runtime state |
| Tool integration — a configured connection to an external or internal system, with its connection parameters and credential reference held once | Tool — one agent’s binding to that connection, with the input and output shapes specific to its use |
| Execution image — a registered container image template | Execution environment — one provisioned, isolated container |
The reason for the split is the same in each case: the specification is canonical, versioned, and shared across many runs, while the instance is operational, mutable, and disposable. Because a run records which version of the definition produced it, work from a year ago remains explainable without freezing the definition in place.
Agent definitions move through draft → approved → deprecated. Only approved definitions are instantiated, which means “who reviewed this agent’s instructions and constraints” is a question with an answer.
Runtimes and isolation
Every span of agent-led work gets its own container, provisioned from a registered image. Isolation is structural rather than a matter of runtime discipline — one execution, one container, torn down when the work completes.
Container termination is cooperative rather than a process kill: the platform requests shutdown, the runtime confirms it, and only then is the environment destroyed. Runtime state is flushed before anything goes away, so nothing an agent produced is lost to a scale-down.
At the deployment level, mDecide runs single-tenant: one dedicated environment per customer, with no data comingled across customers. The architecture overview covers the deployment shape; trust and security covers the isolation posture and shared responsibilities.
Tools and what agents can reach
An agent’s reach is the set of tools bound to it, and that set comes from its approved definition. Two properties follow from how tools are modeled:
- Credentials live with the integration, not the agent. The connection parameters and secret-store reference are configured once on the tool integration. An agent’s tool is a binding to that connection, not a copy of its credentials.
- Connections to your systems of record are read-only by contract where they are configured as sources of data. Writes into downstream systems happen through explicit dispatch in the Act phase, not as a side effect of an agent reading data.
Visualization plugins follow the same discipline from the other side: a plugin emits typed intent and holds no write channel, while the host performs the authenticated write. See data products and plugins.
Foundation models
Agent reasoning is served by a foundation model, registered through a model provider. Anthropic Claude, served through Amazon Bedrock, backs agent reasoning in the reference deployment; custom predictive and anomaly-detection models run alongside the agents in the same environment, so a customer data-science team works where the agents work.
Which model backs which agent definition is configuration. Open standards and a portable data layer are what make that a real choice rather than a stated one: models can be swapped when better ones arrive, without the decision record or the integration work being tied to a vendor.
Bringing your own agents
If your team has already built agents — in LangChain, LangGraph, Bedrock, AutoGen, or a framework of your own — they can join through open standards (MCP, A2A). A governance wrapper gives them the same authentication, audit logging, decision capture, and access controls as the agents mDecide delivers.
The consequence to note is symmetrical: your existing investment is not stranded, and it also cannot bypass the governance contract. An imported agent participates on the same terms as any other.
How people and agents divide the work
mDecide is built for humans and agents working together. Not “people using AI tools,” and not “AI deciding for people” — a structural relationship in which both contribute, both hold authority within a scope, and the boundaries are explicit.
The shape, stated plainly: people bracket the loop, and agents do the work in between.
- People frame the decision — what must be decided, by when, with what at stake.
- Agents pull the data, assemble the evidence, and lay out the options, across however many systems sit behind the decision.
- People review and decide, with the full context, the provenance of every piece of evidence, and the standing ability to override.
- The platform captures the decision and, later, the outcome.
Authority is ordered
Within any deliberation, authority follows a fixed ordering:
Human > Coordinator > Participant > Sub
A human override takes immediate priority. A coordinating agent arbitrates between participating agents. Participating agents do not override each other. Sub-agents work under the direction of a participant or coordinator.
This is not a permissions table bolted on afterward. It is a property of how deliberation is modeled, and it shows up in how overrides are recorded, who may participate in what, and where escalation goes.
Overrides are structured, not improvised
When a person — or, within the ordering above, a coordinating agent — disagrees with an agent’s recommendation, the disagreement is captured as a structured event: which recommendation was being overridden, whether it was accepted, rejected, or modified, the substituted recommendation if there was one, and a required reason.
The reason is mandatory by design. An unexplained override teaches nothing. A recorded one becomes a signal in the Learn phase and, over many cycles, evidence about where the agents are reliably wrong.
Threads, and how attention actually works
Deliberation happens in threads anchored to a specific thing: a material, a decision, an override, a tool invocation, or a dispatch of work. An annotation on a material is simply a thread rooted there. Any participant, human or agent, can start one.
How attention moves through a thread is worth being precise about, because it is easy to assume the wrong model:
- Visibility is thread membership. A coordinating agent sees the threads in its scope; a sub-agent sees nothing independently.
- A mention adds salience, and routes nothing. It asks a participant who can already see the thread to notice it, or to act on it. Intent is read from what was written, not declared as metadata.
- Activation is the recipient’s decision, under the authority ordering above.
- A request aimed at an agent terminates in a recorded outcome — satisfied, declined, or escalated.
- A request aimed at a person never compels and never expires into agent action. Nothing an agent does is licensed by a human’s silence.
- When people are talking to each other, agents hold the floor. They observe, defer any triggered contribution to the next pause, and never adjudicate between people.
A thread can also produce typed follow-ups: a request for additional data reopens sensing, a challenge to a recommendation becomes an override candidate, an escalation puts the question in front of a person at a gate, and a proposed alternative sends the work back into analysis.
Where the checkpoint sits
Human approval is not sprinkled at discretion; it is configured. A phase gate is the structural moment where a cycle cannot advance without a person, placed where the cost of being wrong exceeds the cost of waiting — most commonly between analysis and the decision itself. What the gate checks, and what it will not accept as evidence, is covered in workstreams and phases.
A note on vocabulary
mDecide describes this work as agent-assisted and agent-led, not as automation. The distinction is not cosmetic. Automation implies the person has been removed from the loop, and the platform is built the other way around: the human decision point, the override path, and the recorded account of both are structural. Where scale is being described, the measure is decision throughput rather than decisions automated.
Where to go next
- Workstreams and phases — how agent work is organized into phases and what gates check.
- Trust and security — isolation, identity, audit, and the shared responsibility boundary.
- Tour of one decision cycle — people and agents working a single decision together.