Imagine a team with forty conversations open. In one, someone asks an agent to prepare a customer proposal. In another, a colleague asks for a delivery estimate. A third person is checking whether the same feature can ship this month.
Each conversation starts with a briefing. Here is the customer. Here is what we promised. Here is the decision we made yesterday. The agents get to work, but each sees a different slice. Someone eventually notices that the proposal promises a date the engineering discussion has already ruled out.
Then a Task ends. Its conversation goes quiet. A week later, another person starts a related job and explains the background again.
We kept coming back to this scene while building our agents. We wanted the next piece of work to start with what the team had already learned. That led us to a single-session design: a persistent main conversation, with independent Workers carrying out individual Tasks.
Subagents help divide the work. Single session answers a different question: where does the understanding of that work live over time? We use both. The main conversation gives the team continuity; Workers give each job room to run.
A person, a channel, a team
Poke gave the personal agent a simple home: one person, one conversation (September 2025). It connected a person’s email, calendar, and files to a text conversation. A request to draft a reply or reschedule a meeting could begin in the same place as the previous request. That made the conversation a useful point of return as someone’s day moved on. The personal relationship was the centre of the experience, and it gave us a concrete example of continuity across different jobs.
Claude Tag brought one Claude into a channel (June 23, 2026). Anyone there could tag the same agent, see its work, and pick up where a colleague left off. Claude remembered relevant information over time and worked with the tools administrators made available. The launch also described learning from other channels and sources when permitted. We were interested in the shared conversation: people could delegate work in the place where they were already discussing it. Our own design takes the team’s main conversation as its point of return, across the discussions and Tasks that feed into it.
We chose to explore one team, one conversation. The scope follows the team’s work across discussions. A decision about delivery can inform the proposal, even when those jobs began in different places.
On April 28, 2026, we published our first related article about Bridge, our previous product, placing that part of our exploration after Poke and before Claude Tag. We continued that work in our current product, Comma (October 1, 2026), where this design runs today.
DeepSeek Harness added another exploration on October 31, 2026: Super-agent. Its proactive work in group chats echoes the same direction: moving coordination from people into the system. Its research prototype follows its own design.
DeepSeek’s design article, §8.4 leaves two questions open: cloud compromise or prompt injection exposing connected devices, and credentials leaking through model context. Our running approach to content is IFC: declare sources, check destination readers, refuse disallowed sends, and seek scoped human approval when needed.
Credentials take a separate path. The model names a credential reference; execution resolves and injects its value without returning it to the model.
What the team carries forward
Consider a new colleague joining the proposal work. They join the same main conversation the rest of the team has been using. They can see the decisions shared there, ask why a date changed, and pick up the work without asking three people for three summaries. Workspace membership gives them access to that shared conversation; access to the material behind a decision still follows that material’s permissions.
A completed Task keeps its result and history. Perhaps the team learned that a customer requires an unusual export format. The report comes back to the Router, and a later proposal can refer to that finding and its source. The Task is finished, but the team still has somewhere to return for what it learned.
Parallel work makes that return path important. One Worker may be reading customer requirements while another investigates a technical limit. If their findings reach the team through a chain of retellings, an important qualification can disappear. Each Task reports its findings back, together with the source they came from. The Router receives them in the same main context.
That gave us a reason to split the harness into two roles. One keeps track of the team’s ongoing conversation. The others carry out the individual jobs.
How the Router and Workers share the work
We give a workspace one resident Router. It holds the team’s main context and follows the conversation as requests arrive, decisions change, and results come back. A request about the proposal arrives in the same context as the delivery discussion already under way. Each incoming message carries its source conversation and message identity. The Router shares context across discussions while keeping track of where each input came from.
The Router hands a defined job to a Worker. Each Task starts a fresh Worker session with the instructions and handoff for that job. Other Workers’ histories stay in their own sessions. Several Workers can investigate separate questions at the same time.
We define each Task with a goal, the context for pursuing it, and an expected deliverable. “Investigate this customer” leaves too much unstated. “Check the customer’s export requirements and return a proposed format, with sources and open questions” gives the Worker something it can finish and the Router something it can use.
Suppose the proposal needs both that export check and a delivery estimate. We can send them to separate Workers. One returns the customer’s requirements. The other returns an estimate and the assumptions behind it. The Router brings those results back into the main conversation, where the team can make a decision. The completed work has a route home.
Every visible reply is an explicit send, including a reply in the main conversation. The Router names the destination and passes that destination’s checks. Model output and ending a turn do not publish a reply. The same rule applies when a Worker reports back or addresses another participant. Reading material for a Task gives the Worker context for its work, with sending handled as a separate action.
Information flow control
Parallel Tasks bring together sources with different audiences. Each send declares the sources it uses. Information flow control, or IFC, checks whether the destination’s readers can read those sources.
With enforcement enabled, a refused send returns a reason. The agent can remove restricted material and retry, or seek the required scoped human approval. A retry must revise the content along with its source declarations.
IFC gives the team a checkable step between preparing a reply and sharing it.
Back at the proposal, the Router can present the estimate to the team, ask for the decision that remains, and send the agreed answer through the appropriate channel. The Worker’s job is bounded. The team’s conversation continues through the handoff.
Starting a new Task opens a fresh Worker session. When we switch sessions, we carry unfinished work and its references into the next session. The team still needs a way to return to its earlier decisions.
What the team learns together
Reusable procedures become group-shared skills: editable instructions and resources. The creating agent controls agent-side edits. Other agents can use the skill without rewriting it; a read-only built-in can be copied for customization. Sessions receive the catalog for their scope and open the relevant instructions.
The Router maintains durable memory about people, environments, general facts, and dated episodes. It reads or searches that memory on demand. Ordinary Workers work from Task handoffs; assigned Triage Workers have source-bound read access. Memory writes belong to the Router.
When enabled, the Condensed Workspace gives every internal Router and Worker Session the same short list of current group facts. The workspace owner can edit it directly.
Agent updates receive an advisory check for relevance as current facts useful to other agents. Revisions and the last writer are recorded. The owner can correct or remove statements, making shared assumptions visible and editable. A rejected update can be retried with its rejection ID as an explicit override.
The cost of keeping one conversation
This arrangement puts pressure on the main session. Workers can run in parallel, but the Router still has to bring their results together. A new request can arrive while it is handling an earlier one. People experience that as a queue, however many Workers are available behind it.
We are still working on serial queuing. Delegating a long investigation gives the Router more room to respond, but the team still needs an order for decisions that affect each other. In the proposal, someone has to settle the delivery date before the final promise goes out. A shared conversation makes that dependency easier to see; it also gives the Router more responsibility for keeping work moving.
History brings its own cost. Every finished Task adds something worth considering for later, along with much that will never matter again. As the history grows, finding the right decision and the reasons behind it takes more work.
We want an old decision to be easy to find without asking a teammate to reconstruct the whole discussion. Its reasons help the team recognize when it needs to change.
That is where our exploration stands. We chose a shared main conversation because teams keep returning to the same work through different people and different Tasks. The next time someone opens a related discussion, we want the team’s earlier effort to be there for them.
