Fits your ecosystem
It joins the stack you have.
It does not ask for a new one.
Traces and metrics go to the collector your platform team already runs, from our cloud or from yours. Your internal services become connections your people can hand work to, wherever the software is running. And where something is not built yet, this page says so in the same words.
Observability
It shows up where you already look
A deployment exports OpenTelemetry traces and metrics to a collector you name, on either offer. A setup on our cloud exports to your collector the same way one on your own machines does. Nothing is exported anywhere else, and the exporter is off until you configure it.
| What is exported | What your dashboards get |
|---|---|
| A span per action | Which system was touched, which project asked, how long it took, and how it ended |
| A span per policy decision | Allowed, refused, or parked for a person, with the rule that decided it |
| Job progress | Rows attempted, rows finished, rows still waiting, for work that runs for hours |
| Errors, in your own taxonomy | The stable error names, so an alert you write today keeps meaning the same thing |
Two things follow. Your on-call sees a run beside every other service instead of in a console nobody has open, and the numbers your finance team reads for the license are the numbers your platform team already sees.
On our cloud
A hosted setup still reaches into your stack
Running on our machines does not put your systems out of reach or your dashboards out of the loop. The three things a platform team asks about work from our side of the line too.
Your dashboards
The same exports, aimed at the same collector. Your on-call sees a run from a hosted setup beside every other service, under the naming your team already uses.
Your internal systems
The relay reaches a system that has no public address, dialling out from your network to your setup. Reaching into a network we are not in, without that network opening anything, is what the relay is for.
Your own services
A service your own team wrote is added by describing it, and what you add stays private to your organization. It is not published, not shared with anybody else, and not visible to another customer.
Your administrators set all three up from enterprise.atmon.ai/console. Where a hosted setup sits, drawn, and how the relay reaches inside.
Interfaces
In your building, everything answers on your address
The API, the SDKs and the assistant surface are the same ones the hosted product uses. The only thing that changes is the hostname: wherever the documentation says our address, your systems say yours.
That matters for a reason beyond neatness. Nothing your developers build against a deployment has to leave your network to work, and nothing they build is locked to a hostname they do not control.
- The API. Typed calls over HTTP, with a stable set of error names your alerting can depend on.
- The SDKs. Generated from the same definitions as the API, so a version bump cannot quietly change a field under your code.
- The assistant surface. Your assistants connect over the Model Context Protocol, to your deployment, holding a key your administrators minted.
- The console. A page inside your network, pointed at your deployment rather than at anything of ours.
Your own systems
Internal services become connections
The apps a department works in are not all bought. Some of them your own team wrote, and those are usually the ones the work actually turns on.
Described, not coded
An internal service is added by describing it, the way any connection is described. It becomes actions your people can hand work to, and adding one does not mean waiting for us to write anything.
Private to your deployment
What you add stays in your deployment. It is not published and not shared with another customer. On your own machines it is not visible to us at all, because we are not in the network it lives in.
Same rules, same record
An internal action goes through the same checks as a bought one and lands in the same record. There is no second path with weaker rules on it.
Where the service has no public address, the relay is how a deployment reaches it, and the relay dials out from your side.
Identity, said honestly
Single sign-on is on the roadmap and is not built
This is the question every enterprise buyer asks second, so it gets a plain answer rather than a marketing one.
| Capability | State today | What that means for you |
|---|---|---|
| Accounts and roles | Shipped | People, roles and projects are administered in the console, in your deployment or in the setup we run |
| Invitations | Shipped | An administrator invites a person and gives them a role; nobody self-joins |
| Keys for assistants and services | Shipped | Minted and revoked by an administrator, shown once, stored as a hash |
| Single sign-on, SAML or OpenID Connect | On the roadmap, not built | Your staff sign in to the deployment directly until it lands |
| Directory provisioning, SCIM | On the roadmap, not built | Joiners and leavers are an administrator action, not a directory sync |
Both roadmap rows are part of the license conversation, including when they land and what a deployment does in the meantime. Nothing on this site describes either of them as though it exists.
The short version
Four things your platform team keeps
- Your collector Traces and metrics land in the tooling you already pay for, under the naming your team already uses.
- Your address On your own machines every interface answers inside your network, so nothing your developers build has to leave it.
- Your services Internal systems are added by your own people and stay private to your deployment, on either offer.
- Your record The audit is yours to take either way: a query against your own database where you run it, an export from your console where we do.