I kept hitting the same small failure while building APX: a useful message existed, but it lived in the wrong conversation.
A person would receive a detail in one thread, open another agent session, copy the text, and paste it there. The new agent could read the words, but not their meaning in context. Was this something the owner had just typed? Was it an agent's conclusion? Which project or conversation produced it? Could anyone reopen the original exchange next week?
Copy-paste is fast, but it quietly destroys the facts that make a handoff trustworthy.
So I made forwarding in APX a quote with provenance, not a convenience paste.
The thesis: context needs an address
A forwarded message now carries where it came from, who said it, and when it was said. In the web surface, a message can move to another session in the same project or a different project. The destination receives a quote card rather than an anonymous paragraph.
That is deliberately modest. I did not add a new message channel, a separate forwarding database, or an opaque cross-project synchronization layer. A forwarded item is still an ordinary user turn. It is stored in the same places other turns are stored, so existing conversation views, ledgers, inboxes, and later re-reads do not need a special alternate history.
The turn's metadata holds the structured provenance. The text delivered to the model holds an explicit quote marker containing the source label, speaker, and timestamp. The model and the human therefore get the same important distinction: these are quoted words, not a fresh instruction from the owner.
That dual representation matters. Metadata lets the UI render a readable quote card and navigate back toward its source. The explicit marker lets an agent reason about the quote without guessing where it came from. If I kept only metadata, the model would lose the boundary. If I kept only a magic text prefix, every client would need to parse presentation details from prose.
The small details were the feature
Most of the work was not the forward button. It was deciding what a forward may carry and what it must not pretend to be.
First, the quote is bounded. APX caps forwarded text at 4,000 characters and marks it as truncated when needed. A forward is context, not a back door for injecting a giant transcript or binary-looking tool output into another model's context window. The destination still has room to answer.
Second, the source has a real address. Depending on where the message began, APX records enough information to identify a thread, conversation, or live session. It also records the originating project. That last part is essential when a forward crosses projects: an ID only makes sense inside its own project. Without project identity, a card may point at the wrong conversation or nowhere at all.
Third, author identity stays intentionally simple. The forwarded payload distinguishes the owner from an agent and may include an agent display name. That is enough to prevent the worst ambiguity without inventing a complicated hierarchy of new message types.
Finally, I put the quote before the note the person adds at forwarding time. A message such as “review this and extract risks” is useful only if the agent can first see what “this” is. The quote also uses blockquote lines and a closing marker, so multi-paragraph content does not blur into a new instruction.
Why an ordinary turn was better than a transport feature
I was tempted to treat forwarding as a transport concern: copy a payload from one chat object to another and call it done. That would have created a strange exception. It might work in one panel, yet disappear from a ledger, fail to survive a refresh, or become unreadable on another APX surface.
Making it an ordinary user turn with extra provenance has a calmer result. The destination session owns the new turn. The source remains unchanged. The destination can reply naturally. Existing storage and message shaping keep doing their jobs.
This also avoids an important false promise: forwarding is not shared memory. It does not merge two sessions, make their histories identical, or grant one project access to another project's entire conversation. It carries one bounded quotation, visibly labeled, because a person chose to hand it over.
That boundary is useful for daily work. I can send an agent's investigation from one session to a reviewer in another and ask a focused question. I can move a customer detail from a channel conversation to a project session without presenting it as something I personally wrote. I can revisit the destination later and see both the quote and the instruction that accompanied it.
What I learned
Agent products often make moving text look trivial. But when an agent acts on text, provenance is part of the input. Losing it changes the meaning of the handoff.
The practical rule I am keeping is simple: when context crosses a conversation boundary, preserve the boundary in the artifact. Keep the quote bounded. Name its source. Name its speaker. Keep the original available to reopen. Do not turn a handoff into a silent copy.
That is a smaller feature than “cross-agent collaboration” sounds like. It is also more honest. APX does not need every conversation to become one giant memory. It needs a reliable way for a human to carry one useful piece of context into the next room.
Top comments (0)