Platform and integration · In Development
Simple Atlas

Simple Atlas
The layer that holds the authority an agent is deliberately not given.

For Enterprise platform teams building agentic applications on Azure, and Microsoft Solutions Partners who need an agent to touch a downstream customer tenant without holding the rights to do so.

Solutions Partners are under pressure to ship AI offerings to downstream customers, with neither the engineering capacity nor the budget to build a multi-tenant AI platform from scratch. Simple Atlas is being built as a shared governed platform layer: a Foundry-routed model gateway, a broker that holds an agent request against a customer tenant behind a signed approval and a kill switch, and an evidence trail per tenant. It is deployed for internal review, it has not been adopted by every Simple Intelligence product, and it is not on sale. Partner commercial terms are not set and are not published.

Replaces Build-it-yourself on Azure AI Foundry alone AWS Bedrock AgentCore Custom LangChain stacks Vercel AI SDK plus Supabase
Web In development Copilot Planned

When you can get Simple Atlas

Coming soon

Not open yet. Tell us where to send word when it is.

What you can do now

Get product updates

None of these creates an account, a trial, or access. Each one records what you asked for so a person can answer it.

Where this stands

Availability
Coming soon

What it costs

No published price yet. Pricing is set before this product opens.

Routes that are not open

  • Direct trial with Simple Intelligence Not open yet
  • Direct subscription from Simple Intelligence Not open yet
  • Microsoft Marketplace Not published yet
  • Sponsored subscription for member companies Not open yet

Simple Atlas on the same scale as everything else here

Every Simple Intelligence product is placed on one five-stage scale, so a stage means the same thing on this page as it does on any other. Nothing here is a schedule.

  1. Done

    Planned

    Scoped and specified. Not being built yet.

  2. Now

    Building

    Under active development.

  3. Not started

    Validation

    Built, and being tested against real work before anyone outside is let in.

  4. Not started

    Early access

    Open to a reviewed group, with onboarding run by a person.

  5. Not started

    Available

    Open to anyone who qualifies, without waiting for a review.

This is where the product sits, not what you can do with it today. What you can do is the button at the top of this page, and it is worked out separately from evidence about the product rather than from this scale.

A platform layer, not a product you run your day in.

Nobody logs into Simple Atlas to do their job. The operational products do that. Atlas is the layer underneath them that answers two questions the products should not each answer separately: which model handles this request, and what is this agent allowed to change in a customer tenant. Both answers have to be the same everywhere, which is why they live in one place instead of being reimplemented once per product.

The gate order is the product.

An agent here can ask for an action and cannot take one. The broker runs a fixed sequence before anything happens: the kill switch is checked first, then the approval signature and every field it was signed against, then whether the adapter matches the action that was approved and whether that action can be undone, then an explicit acknowledgement if it cannot, then a replay check, then a re-read of the live target to confirm it still looks like what the approver reviewed, and only then the execution and the evidence record. The order matters more than any single gate, because it is what stops an approval from being reused, widened, or applied to a system that changed after somebody said yes.

What state it is actually in.

The broker, the gateway, the operator console, and the entitlement path are built and deployed for internal review. Nothing here is sold, listed, or open to customers. There is no price on this page because partner and platform commercial terms have not been set, and a number published before that decision is a term a buyer would quote back at us.

What runs today, and what is still a plan.

Atlas is further along than most things marked in build, and it is still not something a customer can obtain. Both halves are below.

Working today

  • The capability broker runs the full gate order, refuses on a tripped kill switch, a mismatched approval, an unacknowledged irreversible action, a replayed nonce, or a target that changed after review
  • The model gateway routes a request to a model by the intent behind it rather than by a hardcoded choice, per tenant
  • An operator console exists over capabilities, approvals, grants, evidence, and the kill switch
  • Entitlement grants are written durably and drained through an outbox, so a grant survives the service that issued it restarting
  • Records live in Postgres with pgvector, which is the portfolio default for anything that has to be provable later

Not yet

  • It is deployed for internal review only. There is no sign-up, no trial, no price, and no way for a customer to obtain it
  • It is not listed on Azure Marketplace or AppSource. Both are planned distribution and neither is live
  • Simple Bridge, the planned customer-facing registry and federation layer, is planned and unavailable. There is no interface, no date, and no way for a customer to reach it
  • Partner commercial terms, including any revenue split, are not decided and are not published
  • The Microsoft Solutions Partner certified-software designation is a target and is not held

Verified against the product on 2026-08-24.

Simple Bridge is the planned front door to this layer, and it is a plan.

It is named here because a platform page that hides its roadmap is harder to evaluate than one that states it. What follows is what the name refers to and how far along it is.

This describes what exists in the product today. It is not open to customers yet, and nothing here is available to buy, install, or sign in to.

What it would be

A customer-facing registry of the capabilities and tool servers a tenant has turned on, and the federation point where one Simple Intelligence product can call another under the same approval rules.

How far along it is

It is planned and unavailable. Whatever has been tried internally does not amount to a customer-ready federation layer, and there is no interface, no date, and no way to reach it. Read it as a direction, not as something arriving.

The name itself is not settled

A trademark review covering it is open and unresolved. If the review lands badly the layer keeps its function and loses its name, which is another reason not to plan around the word.

It is not a separate product

There is no Simple Bridge page, no way to buy it, and no separate listing. It is a part of Simple Atlas, and if it ships it ships as part of Simple Atlas.

Underneath the products, not beside them.

The portfolio has a planned operational suite, a planned shell, and a platform tier. Atlas is the third, and the relationships are one-directional.

The products call it

When an operational product needs a model or needs to change something in a customer tenant, it goes through this layer. That is the whole relationship. A customer buying one of those products is not buying Atlas.

Simple Ops is not this

Simple Ops is the planned grouping of the operational applications, which is a different question from what those applications run on. Atlas is not a module inside it.

SimpleOS is not this either

SimpleOS is the planned shell a customer would compose their own products in. It is a surface. Atlas is what sits under the surface, and neither one implies the other exists.

SimpleForge solves the other constraint

Atlas governs what an agent may change in a tenant. SimpleForge is for the case where the data cannot leave the customer at all. They are separate answers to separate problems.

Where a tool call goes, and what has to happen before it lands

This is the design direction rather than a running topology. Each step states its own maturity, one of them is planned and unavailable, and none of it is something a customer can reach today.

In sequence: Product-owned MCP servers, scoped to one tenant (Gated), then Simple Bridge discovery and federation (Planned), then Simple Atlas governed model and capability plane (Gated), then Human approval (Gated), then Governed result and evidence (Gated).

  1. Product-owned MCP servers, scoped to one tenant

    Gated

    Where a product embeds a tool server, the tenant scoping is enforced inside that server rather than trusted to whoever is calling it. Each product owns its own, and how far along they are differs from one product to the next.

  2. Simple Bridge discovery and federation

    Planned

    Planned and unavailable. It is the point where one product would discover what a tenant has turned on elsewhere and call it under the same rules. There is no interface, no date, and no way to reach it.

  3. Simple Atlas governed model and capability plane

    Gated

    Deployed for internal review. Model access routes through Azure AI Foundry, and an agent's request for an action is held behind a signed approval, a reversibility check, and a re-read of the live target before anything executes.

  4. Human approval

    Gated

    A person approves the specific action and the specific fields it was asked against. A consequential action still has to pass the approval seam of whichever product owns the record, because that product is the one authoritative for it.

  5. Governed result and evidence

    Gated

    The result and the evidence record settle together, per tenant, so that the record of what happened is not a separate thing that can be missing.

Implementation maturity varies by product. A capability is not treated as available on this site until tenant scoping, authorization, and durable audit behaviour have been verified for the specific product that offers it.

What this diagram does not say

  • Implementation maturity varies by product. Nothing here is a portfolio-wide guarantee.
  • Simple Bridge is planned and unavailable.
  • There is no unrestricted portfolio-wide MCP server, and there is not going to be one.
  • MCP is not a bulk synchronization protocol. It is a call-and-answer interface for individual tool calls, and it does not copy one product's records into another.
  • Each product remains authoritative for its own records.
  • A consequential action requires the approval seam of the product that owns the record, not just approval at this layer.
  • The models behind the gateway are Azure OpenAI and other Azure AI Foundry models, not a consumer chat service.
  • Provider-neutral and bring-your-own-model language belongs here only where implementation and configuration prove it. Today that is a direction rather than a shipped capability.

The human decision in this sequence

What a person reviews
The specific action an agent has asked to take, and the fields it was asked against.
What gets approved
The signed approval, bound to those fields. Every field the approval was signed against is matched before anything runs.
What approval makes possible
The broker executes that action through the adapter that matches it, and only that one. An approval cannot be widened into a different action.
What invalidates it
The live target is re-read immediately before execution, and if it no longer looks like what the approver reviewed, it refuses. A replayed approval is refused. Binding an approval to a hash of an exact change set is a separate mechanism that is designed and not built, and this page does not claim it.
How failure is detected
A refusal names the gate that refused. A tripped kill switch stops every execution and is checked before any other gate, so a stop is not something the rest of the sequence can talk its way past.
Recovery and escalation
An action that cannot be undone needs an explicit acknowledgement before it can proceed at all, and where an action can be undone the reversal is what recovery uses. Escalation is to the operator console, where the kill switch, the approvals and the evidence are visible in one place.

This is deployed for internal review. It has not been adopted by every Simple Intelligence product and no customer can reach it today.

Where each of these claims comes from.

An agent can request an action against a customer tenant and cannot perform one.
In the build The broker is the only path to execution and it runs a fixed gate sequence before it. Each gate has a named rejection reason, including a tripped kill switch, a reversibility-class mismatch, an unacknowledged irreversible action, and a detected replay. The gate order is documented in the code that enforces it rather than in a separate policy note. Checked 2026-08-24
An approval cannot be reused, widened, or applied to a target that changed.
In the build The signature is verified against every field the approval was bound to, and the requester and the approver must be different people. A single-use token is consumed atomically at execution, and the live target is re-read and compared against what the approver reviewed before anything is written. Checked 2026-08-24
The kill switch is checked before anything else.
In the build It is the first gate in the sequence, ahead of approval verification, so a tripped switch stops even a request carrying a valid and current approval. It is one of the surfaces the operator console exposes. Checked 2026-08-24
An entitlement grant survives a restart of the service that issued it.
In the build Grants are written durably and delivered through an outbox that drains and requeues rather than being emitted once and forgotten, with its own health and authentication path. Checked 2026-08-24
It is not distributed through any channel today.
Published standard There is no published listing on either planned channel, the Solutions Partner designation named as a target is recorded internally as not held, and the payment channel a listing would need was removed from the legal pages because it did not exist. Checked 2026-08-24
Storage posture
Persistent (Postgres + pgvector)
Certification target
Microsoft Solutions Partner certified-software designation, Financial Services AI track
Distribution
Azure Marketplace (planned) · AppSource (planned)
Status
In Development
Industries

How ICM informs Simple Atlas

Simple Atlas is the substrate the other agents call when they need to change something in a customer tenant. It exists because the agent is deliberately not entitled to make the change itself, and an approval card next to the execution path is not the same as an authorisation gate in front of it.

Built, and verified against the product code

  1. Context in

    An agent describes a change it wants

    The broker holds the administrative authority and the agent holds none. An agent can state an action it would like taken. It cannot take one, because it never holds a token that would let it.

    Gated

  2. Retained or discarded

    Identity comes from the connection

    Tenant and caller are taken from the authenticated connection, never from the request body. A build test fails if those field names reappear in a request schema, which makes the rule harder to undo than to keep.

    Gated

  3. What the agent proposes

    A closed capability registry

    The request has to match a capability that already exists, with a declared reversibility class. The registry is closed: adding to it takes a written decision record, not a configuration change, and the adapter that runs has to match the reversibility the approver was shown.

    Gated

  4. Human review a person decides

    A signed approval from a different person

    The approval is a signed token bound to every field of the request and to an expiry, and verification includes checking that the requester and the approver are not the same person. An irreversible action needs that acknowledged explicitly.

    Gated

  5. Permitted effect

    The world is rechecked before the change

    Preconditions are read live and compared against the hash captured when the approver reviewed them. If the state changed in between, the action is rejected as stale rather than executed against a situation nobody looked at.

    Gated

  6. Evidence recorded

    One-time consumption, then evidence

    The approval is consumed atomically before execution and the outcome is written afterwards. A failed execution still consumes it, so retrying requires a fresh approval instead of another attempt at the old one.

    Gated

  7. Failure and refusal

    The kill switch fails closed

    The first check is whether the customer has stopped the broker, and a stopped broker rejects everything. A test fails the build if a second call site to the execution path appears, because a kill switch with a way around it is not a kill switch. Requests that do not fit a capability are rejected as excluded rather than approximated.

    Gated

These labels describe each step of this workflow on its own. They are not the availability of the product, which is the status shown at the top of this page.

This describes how the workflow is built. It is not a statement about availability, which is the status shown at the top of this page. ICM informs how context, review and evidence are designed here. It does not replace this product's database, its tenant isolation, its Entra identity, its audit tables, or its authorisation checks.

Methodology note

ICM was developed by Jake Van Clief and David McDermott. Simple Intelligence Group did not originate the methodology.

Simple Intelligence Group applies relevant ICM principles to context, provenance, traceability, human review, and workflow design.

Participation does not imply certification, endorsement, partnership, or an official ICM Architect designation.

The questions a platform team asks first.

Can I buy Simple Atlas today?

No. It is deployed for internal review, it is not listed anywhere, and no price has been set. If you want to be told when that changes, ask and we will come back to you.

Is this on Azure Marketplace or AppSource?

No. Both are planned distribution channels and neither has a live listing. Any page, ours or anyone else's, that says otherwise is wrong.

What stops an agent from doing something nobody approved?

The agent cannot execute. It can only ask. The broker checks the kill switch, verifies the approval signature against every field it was signed for, confirms the adapter matches the approved action and its reversibility class, requires an explicit acknowledgement for anything that cannot be undone, rejects a reused approval, and re-reads the live target before acting. A failure at any gate is a refusal with a named reason, not a retry.

What is Simple Bridge?

The planned customer-facing registry and product federation layer inside Atlas. It is named in the plan, has no implementation, and its name is subject to an unresolved trademark review. It will not become a separate product with its own page or its own purchase path.

What happens to the data that passes through it?

Records that have to be provable later, meaning grants, approvals, and evidence, are stored durably in Postgres with pgvector, per tenant. What an approval was for and what happened as a result is the record; the point of the evidence trail is that a past decision can still be shown. If you need content never to be stored at all, that is a different posture and it is the problem SimpleForge is built for.

Is there a partner program, and are the commercial terms set?

Not a decided one. Partner commercial terms including any split are open, and nothing on this page should be read as an offer. The partner page says the same thing and for the same reason.

This is a layer, so there is nothing to sign up for.

Simple Atlas is not sold on its own and is not open to customers. If you are evaluating what the products above it are allowed to do inside your tenant, that is a conversation worth having now, and it is the one this page is here to support.

Availability Get product updates