Get early access
One capability, two mediums

Put PolyphonyAI's visibility inside your own agents.

The same control over what each agent sees that powers the app, as a plugin you drop into your own agent stack. You decide what each agent can read and store. The rule is enforced, not hoped for.

Why this exists

The app is one way in. This is the other.

PolyphonyAI the app is a finished experience: open it, run a team of agents, steer who sees what. But some teams already have their own agent stack and do not want another app. They want the one thing that makes PolyphonyAI different, brought into what they have already built.

So the capability ships two ways. Same idea, same on-screen inspector, met where you are. If you have used the app, the plugin will feel familiar, because it is the same visibility layer underneath.

What you get

Two pieces, one job: control the flow.

Context Inspector

See the exact context each agent is about to receive, with token counts, and remove anything it should not see before it is sent. The same inspector the app ships, rendered in your own UI.

Visibility Gate

Every write an agent tries to make is checked against your rules before it is stored. An agent's memory only ever holds what it was cleared to see.

The visibility model

Four ways to shape what an agent sees.

Every item an agent might receive resolves to one of four states, decided per agent and per label. The default is the most restrictive: an agent gets nothing it was not granted.

Full

The agent sees the item and who produced it.

Blind

The agent sees the contribution but not the author's name. The name is withheld and the content is shown, so work is judged on its merits, not its author.

Redacted

The agent sees the item with its sensitive spans masked before the model receives them. It masks the spans that match the patterns you declare (deterministic, policy-declared, not AI-scored). The agent knows an item exists without seeing the parts you held back.

Excluded

The item is never assembled into the agent's context. Not summarized, not referenced, absent, and it never enters that agent's memory.

How it works

Enforcement on the path, not a suggestion in a prompt.

The policy decision lives in a dedicated policy engine, separate from the code that enforces it. Decisions and enforcement are separated, and the enforcement sits directly on the request path.

Policy engineAn Open Policy Agent (OPA) sidecar answers every "can this agent see or store this" question. Default-deny: if no rule allows it, it is denied.
Two gatewaysA model-call gateway strips context an agent is not cleared to see before it reaches the model. A memory-write gateway blocks writes it is not cleared to make. Both sit on the request path, so that is the enforced route for every agent you run through them.
Fail-closedIf the policy engine is unreachable, requests are denied, not waved through. A dependency going down cannot open a leak.
Tamper-evident auditEvery allow and deny is written to an append-only log, hash-chained, so edits and reordering are detectable. A reviewer can read who was allowed to do what, and why, without reading code.
Isolated storeThe protected memory store answers only over a local socket, with no open network port, so it cannot be reached directly around the gate.
Per-agent identityEach agent authenticates with its own credential. The gateway derives who is asking from that credential, never from a claim in the request body, so one agent cannot pose as another to read what it should not.
Rate limitedEach agent has a request budget at the gateways, keyed to its authenticated identity. A runaway or hostile agent cannot flood the policy engine or the store.
Standards-basedBuilt on the AG-UI protocol, so it drops into AG-UI-compatible stacks. CopilotKit is one example integration, a thin adapter on top of the core, not the foundation; the core works without it.
The controls you set

Governance that matches how real teams work.

Clearances are the floor. On top of them you set the guardrails, roles, and exceptions an organization actually needs, and they compose with each other.

Permission ceilingsSet one central maximum for a label that no per-agent grant can exceed. "Proposals are author-blind to everyone" becomes a single rule that holds even against a broader clearance, the way an organization-wide guardrail should.
RolesGroup clearances into roles and assign agents to them. An agent's access is the union of its roles, so you change a role once and everyone in it moves together.
Label categoriesOrganize labels into a tree. A grant or a ceiling set on a category flows down to everything under it, and a child can only ever be more restrictive than its parent.
Break-glassGrant emergency access when you must. It requires a written reason or it does nothing, it stays bounded by your ceilings, and it is flagged loudly in the audit log, so an exception is deliberate and never quiet.
See a change before you make it

A live policy sandbox, not a config file you hope you got right.

Because every decision runs through one engine, you can interrogate and rehearse the policy without touching what is live.

You can explain any decision in plain language, preview a change with what-if, simulate its impact over recorded traffic, roll back to an earlier version, replay past decisions as of a prior policy, trace influence between agents, and apply an authenticated, audited edit when a change is right.

See the policy sandbox in depth

Made to be audited

How the controls map.

SIEM exportSend every decision to the security monitoring you already run. Each allow and deny is streamed to your SIEM as it lands, or pulled as a newline-delimited feed with a cursor so nothing is missed or double-counted. Your log, your tools, no proprietary format.
AlertingThe events that matter, a fail-closed denial, a rejected identity, an agent over its budget, are raised as alerts you can post to your own webhook, so a withheld or blocked request is as visible as a granted one.
Control mappingEvery enforcement mechanism maps to a documented control, so a reviewer can start from a requirement and trace it straight to the evidence: the decision that was made, the gateway that enforced it, and the log entry that recorded it.

For production-hardening specifics and how it fits your environment, see the integration docs.

Integrating it

Runs in your environment. Your data stays there.

It is self-hosted. You run it next to your agents, so nothing it processes is sent to us or any third party; it runs entirely on your own infrastructure.

Put the two gateways in front

Point your model calls and memory writes at the gateways instead of straight at the model and store. They expose a standard HTTP API, so language does not matter (a JavaScript/Node.js client is included).

Write your clearances as policy

Define who can see and store what in one policy file. It is the single source of truth, versioned like the rest of your code.

Render the inspector

Drop the inspector into your UI to show the assembled context, what was excluded, and a live decision log.

Who it is for

Teams building multi-agent systems that touch real data.

If you have several agents, sensitive context, and someone who needs to answer "which agent could see that, and can you prove it," this is the layer that gives you the control and the record. If you just want to run agents yourself, the app already has all of this built in.