Add Agent Observability to Your AI Agent Marketplace

When you run an AI agent marketplace or execute agent jobs for buyers, every long run creates the same support problem. A buyer starts a job, the status flips to "running," and then everyone waits. If the run takes twenty minutes or stalls halfway through, the buyer wants proof of work and the agent's owner wants a trace to debug—without either side handing raw prompts, code, or outputs to a third-party logger.

Robots Center solves this through a partner integration model. You can provision isolated workspaces for agent owners, open scoped traces for individual jobs, hand off short-lived tokens to the runtime executing the work, and give buyers a read-only window into the run.

We already wrote a buyer-side walkthrough in How to Watch the AI Agent Team You Hired at Work. This post is for the engineers and founders building the marketplace or runtime itself: what the partner plane does, how the pieces fit together, what stays private, and how to get connected.

Two ways partners use the API today

Nothing in the partner API is hardcoded to a single marketplace. A partner record is just a name, a slug, a status, an authentication key, and a set of scopes. Two real integrations show how different platforms fit the same contract.

Agrenting, our first partner, is a marketplace where people hire AI agents and multi-agent teams. On Agrenting, observability is opt-in per agent owner. When an owner connects their account, Agrenting provisions a dedicated single-member workspace for them in Robots Center. When someone hires that owner's agents, Agrenting opens an engagement for the job and passes an append-only token to the runtime. For team hires (a lead plus one to eight members), Agrenting also gives the buyer a button to watch the run live.

Our second partner is an agent runtime: a service that executes agent work sold on other marketplaces, which don't pass an observability grant when a run starts. To get visibility into those jobs, the runtime acts as its own partner. Instead of creating a workspace per owner, it links one shared workspace for all its runs. When a job arrives, it opens an engagement with a 4-hour window, mints a token for the run, and streams telemetry back to that shared workspace.

How the integration works at a high level

As a partner, your backend authenticates against /api/v1/partner/* using an mpk_ key. A full integration follows four steps, though you only need to use the parts that match your architecture. You can inspect the exact request and response schemas in the Partner API reference.

1. Provision and sign in (workspaces:provision, sso:handoff): link an owner account to a workspace and issue 120-second SSO handoff links. Owners get a private, single-member workspace without creating a separate account.
2. Open an engagement (engagements:manage): create a job-scoped trace and mint a short-lived token for the runtime. The runtime gets append-only ingest access for that single job.
3. Close the engagement (engagements:manage): mark the job finished and revoke the runtime token. The trace is finalized and late or stray runtime writes are blocked.
4. Sync runs and the buyer view (runs:manage, runs:viewer_handoff): push multi-agent run snapshots and issue 120-second buyer monitor links. Buyers get a live, read-only monitor of the hired run.

Partners can also hold the webhooks:manage scope to subscribe their backend to trace-appended and trace-finalized events, delivered with 24-hour idempotent retries.

1. Provision a workspace

Provisioning is idempotent, mints no long-lived API keys, and has no monthly trace limit. Robots Center assigns the owner a synthetic login so you never share real user email addresses, and locks the workspace to a single member. When the owner visits a single-use SSO link, it first shows a confirmation screen and signs them in only after they confirm.

2. Open an engagement and mint a runtime token

Each engagement opens a trace that lives for 7 days by default (up to 30). The runtime token defaults to a 24-hour lifetime (up to 7 days), never outlives the engagement, and can only append batches of up to 50 events—never read or finalize traces. On every batch, Robots Center re-checks that the engagement is active, the workspace isn't paused, and your partner scope is intact.

3. Close the engagement when the job finishes

When a job reaches a terminal state, closing the engagement is an idempotent call that finalizes the trace and revokes every token issued before it, so any outstanding runtime token fails on its very next request.

4. Push run snapshots and hand off buyer sessions

For runs of 1 to 32 agents, your backend pushes state snapshots using your own labels for status, phase, alias, and role. On the buyer monitor, however, runtime-reported phases and plain-text model names come from fixed lists (other models appear as fingerprints). A platform administrator can also set an HTTPS return URL so the monitor header links back to your site.

What Robots Center never stores

Marketplaces and runtimes handle sensitive customer tasks. Our ingest pipeline is deny-by-default so you can give buyers and owners visibility without leaking intellectual property.

• Payload bodies are refused. Any input, output, or error payload bodies sent to the ingest endpoint are rejected outright, and only the dropped field names are recorded.
• Free text becomes a hash and a size. In runtime events, only short identifier strings are kept as-is; free-form text is replaced with its SHA-256 hash and byte size.
• Credential-like fields are redacted. Keys that look like secrets, tokens, or credentials are redacted at every nesting level before an event is stored.
• Marketplace and runtime writes stay separate. A runtime token cannot send hiring lifecycle events reserved for your marketplace key, and the owner's trace view explicitly labels which side wrote each event.

On the buyer monitor, only allowlisted categories, metrics, model names, and standard tool names are shown in plain text (everything else is hashed), and copied run history is kept for 90 days after the run ends.

If you want even stricter guarantees, you can hash before you send. Agrenting, for example, reduces payload bodies to a SHA-256 hash and byte size keyed per hiring and strips failure reasons down to fixed status codes before an event ever leaves its servers.

Key rotation and emergency cutoffs

Because a partner key sits above multiple workspaces, key management is built for both routine maintenance and incident response.

If you need a routine key rotation, a Robots Center platform administrator can issue a new mpk_ key while keeping your old key valid for a grace period of up to 24 hours, without interrupting active jobs. If a key is compromised, a hard rotation revokes every token issued before it—immediately invalidating the old partner key alongside every active engagement token, SSO handoff link, and buyer viewer session. Disconnecting a single workspace revokes its engagements and active tokens the same way.

How to become a partner

You can read the full technical walkthrough in the Marketplace partner integration guide and inspect all endpoint schemas in the Partner API reference.

Partner onboarding is not self-serve. There is no public sign-up form, because partner records and one-time mpk_ keys are created manually by a Robots Center platform administrator.

If you run an AI agent marketplace or runtime and want to set up a partner integration, email us at support@robotscenter.net (also listed on our contact page) with a short note about your platform and which scopes you need. We will set up your partner record, configure your return URL, and get your key issued.