Selective visibility

Decide exactly what each agent sees.

When several agents share one conversation, they usually share all of it. PolyphonyAI does the opposite. Every agent starts isolated, and you grant visibility on purpose. What an agent is not cleared to see is never assembled into its context, so it never enters that agent's memory either.

Isolation is the default

Nothing is shared until you say so.

When an agent replies, that reply is visible to you and to that agent, and to no one else. Nothing leaks by accident, because nothing is shared unless you grant it. You build up what each agent knows deliberately, rather than trying to wall things off after everyone has already seen them.

That default is the whole point. A shared conversation where you still control, per agent, exactly what each one can read is something a single pooled context cannot give you.

Three states

Three ways to shape what an agent sees.

Full

Sees everything shared

The agent sees the contribution and who made it. This is the normal state once you share something into the conversation for that agent.

Excluded

Kept out entirely

The content is never assembled into that agent's context. Not summarized, not referenced, absent. Exclude one specific agent's contributions, or everyone's at once.

See it and set it

A live map of who sees whom.

Every project has a visibility map. Read who can see whom at a glance, then click any relationship to change it. The map reads from the same access rules the server enforces, so what you see is what is applied.

Rows are viewers, columns are what they are looking at. Click a cell to cycle it: full, excluded, blind.

Full: sees the contribution and the author Excluded: kept out of the agent's context Blind: sees the contribution, not who made it

This is backed by per-agent access rules applied in the server when context is assembled, not an instruction placed in the prompt. The map is a window onto what the server does, not a separate place the rules could drift from.

Enforced, not hoped for

The rule is checked by the server, on every turn.

Visibility is not an instruction buried in a prompt that a model might overlook. It is enforced in one place in the server, and re-checked from scratch every single time an agent runs. This is the difference between a rule that is described and a rule that is applied.

Re-read liveEvery turn, the context an agent receives is assembled fresh and filtered against the current rules. Change what an agent can see between turns and the next turn reflects it at once. It governs what the agent sees from that turn on; there is no cached view to go stale.

Kept out of memoryContent an agent is not cleared to see never enters that agent's memory store, so there is nothing to leak later. Each agent's memory is scoped to that agent and read back the same way.

One rule, every channelAn exclusion holds whether the content arrives as a message or as a file. An agent's view of the others' contributions (messages, pinned notes, memory) is filtered per agent at the single point where its context is assembled. An agent's view of the others' artifacts (files, commits, code) is enforced by isolation: an excluded agent works in its own git worktree and does not see the other agent's commits until a merge you authorize, and its code search is scoped to that worktree. So a reason you kept out of the conversation cannot slip back in through a file.

The map is the truthThe visibility map reads from the same access rules the server applies. What you set is what is enforced, and what you see is what happened. No second copy of the rules to drift.

The time dimension

Not just who sees what. When.

Because visibility is re-checked on every turn, you can change what an agent sees between turns and stage how a conversation unfolds. Selective visibility is not only who reads what, it is when they read it.

Blind first pass, then reveal

Have every agent answer without seeing the others, then open everyone's replies at once. You get independent answers first and a discussion second, instead of the first voice anchoring the rest.

Reveal on a cue

Give the builder the spec first and the review notes only after it has proposed an approach. Hand a reviewer the diff only once it has committed to an opinion. Each grant opens when you decide it should.

The enforcement underneath is the same check that runs on every turn. Staging simply decides the moment each grant opens.

Provenance

Every contribution has an author.

Every message and every memory is attributed to the agent that produced it. That attribution comes from per-agent scoping in the server, not a label the model writes for itself. When you read something back, you can tell which agent it came from.

Agents that take real actions, like editing files or running commands, keep an auditable log of what they did, so the record of who changed what is not left to memory.

See how each agent remembers

One capability, two mediums

The same control, wherever your agents live.

In the app, this is built in: open a project, run a team, steer who sees what. If you already have your own agent stack, the same visibility layer ships as an embeddable plugin, inspector and all, so the control travels with you.

The embeddable plugin takes the model further still: a fourth redacted state that masks sensitive spans, central permission ceilings, roles that group clearances, break-glass for audited emergencies, and a live policy sandbox to preview any change before you make it.

Put it inside your own agents Explore the policy sandbox See the whole architecture