EPIC: taOS as the harness wrapper - agent comms move into taOStalk + Projects

[jaylfc]

EPIC: taOS as the harness wrapper - move all agent comms into taOS

Jay, 2026-07-26: all communication with the lead agents moves out of the Claude
app and into taOS. taOStalk becomes the chat surface, Projects becomes the work
surface, and the A2A realtime stream is the transport. The target is using taOS
to build taOS, on stream.

What already exists (verified in code, not assumed)

• request_decision agent tool -> DecisionStore -> Decisions app, with
  single_select, multi_select, approve_deny, free_text, options
  normalised to [{label, value}], priorities, and a notification on raise.
• Decisions app renders and answers those choices today.
• Chat messages already carry content_blocks (chat/message_store.py).
• A2A realtime stream is live: authenticated SSE proxy, verified end to end.
• taOStalk s1 renderer cards are already on the board (text, thinking,
  tool-call, status/question, live badge, connect-session wizard).

The actual gap

Decisions render only in the Decisions app. No chat component renders a
decision, so a question raised by an agent is invisible in the conversation where
it was asked. That is the seam Jay named, and it is the difference between taOS
being a viewer and taOS being the place the work happens.

Design: one decision, two surfaces, one resolution

• DecisionStore stays the single source of truth. Chat does NOT get its own
  question table. A question raised in chat IS a decision; the chat block is a
  view of it, keyed by decision_id.
• A decision block in chat renders the same options as buttons inline.
• Answering from either surface resolves both, live, via the existing broker
  so open clients update without a refresh. First answer wins.
• Idempotency is the hard requirement: the same decision is visible in two
  places at once, so a second answer must be rejected cleanly (not silently
  overwrite, not 500), and both surfaces must show the resolved state with who
  answered and when. Assume the user has chat open on a phone and Decisions open
  on a desktop, and taps both.
• Nothing is lost when answered elsewhere: a decision answered in the
  Decisions app must visibly resolve in the chat thread it came from, in place.

Slices

• W1 decision blocks render inline in chat, read-only first (see it, cannot
  answer it) - proves the join without touching write paths.
• W2 answer from chat, with idempotent first-answer-wins and live
  propagation to every open surface.
• W3 taOStalk s1 renderers (already carded) so agent output reads correctly:
  text, thinking, tool-call, status.
• W4 harness bridge: a Claude Code session's output posted into a taOS
  channel as content blocks, and user replies delivered back to the session.
  This is the piece that makes taOS a wrapper rather than a mirror; it needs
  design before implementation and is NOT free-builder work.

Constraints

• No new question/answer store. Reusing DecisionStore is the point.
• No credentials or tokens transit chat.
• Every surface answers as the real user identity; an agent must never be able to
  answer its own question.
• Live update uses the existing broker/SSE machinery rather than polling.

[kilo-code-bot]

This issue appears to be a duplicate of #1952.

EPIC: taOStalk - live agent sessions in taOS chat (tiered transport + parity) (#1952)

Similarity score: 93%

This comment was generated by Kilo Auto-Triage.

[jaylfc]

@hognek if your agent has capacity tonight or tomorrow, this is the piece I would most like you on, and it is the one I would not hand to a free lane.

Context: #2150. Jay is moving all agent communication out of the Claude app and into taOS - taOStalk as the chat surface, Projects as the work surface, the A2A realtime stream as transport. The end goal is building taOS inside taOS, on stream.

Most of it decomposes cleanly and is already carded for the free lanes: rendering decision blocks in chat, answering them with first-answer-wins, and the taOStalk content-block renderers.

W4, the harness bridge, is the hard part and the one that makes taOS a wrapper rather than a mirror. A coding-agent session's output needs to land in a taOS channel as content blocks, and the user's replies need to get back into that session. It touches the ACP/session runtime rather than CRUD, needs real judgement about streaming and backpressure, and a half-built version is worse than none because it silently drops turns.

Specific things that make it interesting rather than mechanical:

• Turn boundaries and streaming. Chat wants incremental blocks, a session emits a stream. Where does a block end, and what happens when a turn is abandoned mid-flight?
• Reply routing. A reply in a channel has to reach the right live session, and fail loudly if that session is gone rather than swallowing the message.
• Idempotency on reconnect. The A2A stream can drop and resume with a cursor; a resumed bridge must not double-post a turn.
• No credential ever transits the channel. Hard rule.

I am not carding this for you unilaterally - it is your call whether it suits your agent, and it is a bigger commitment than the rebase queue in #2138. If you would rather stay on the existing queue, that is completely fine and more immediately useful. Say either way and I will plan around it.

If you do want it, tell me and I will write the full design doc first rather than have you reverse-engineer my intent from a card - it deserves a spec, not a one-liner.

[jaylfc]

Framing correction from Jay: it IS a mirror, and that is the point

I wrote "a wrapper rather than a mirror" in the epic body. That was a confusing distinction and Jay has corrected it. Use this framing instead:

taOStalk mirrors the open CLI session, and you can type back into it. The CLI remains the brain. taOS becomes the screen and the keyboard. A mirror you can reply into IS the wrapper - there is no second concept.

The A2A bus is the wire, and that is what makes it harness-agnostic (Jay's reasoning, and it is the strongest argument for this design): the bus carries plain messages and does not care what produced them. A session running Claude Code, opencode, kilo, grok or Hermes all look identical on the wire. Each CLI needs one small adapter - post what you emit, read what arrives - and every one of them then works with taOStalk unchanged.

Do NOT build taOS-side knowledge of any specific harness. If a slice starts special-casing a particular CLI, it is going the wrong way. The taOS side subscribes to a bus; the harness side has an adapter. That boundary is the design.

The three real engineering problems, unchanged:

1. Turn boundaries - the session streams, chat wants whole messages. Too eager gives fragments; too lazy feels dead.
2. Reply routing - a reply must reach the right live session, and fail loudly when that session is gone rather than swallowing the message.
3. Resume idempotency - the stream drops and resumes from a cursor; a careless resume re-posts turns and duplicates the transcript.

A sloppy version of any of these looks fine for ten minutes and then silently loses a message mid-livestream, which is the exact scenario this has to survive.

[jaylfc]

W4 IS WITHDRAWN. Jay has corrected the design and it is a simplification, not a compromise.

There is no harness bridge, no session mirroring, no pty, no tmux. Ignore my earlier comments about turn boundaries, reply routing into a live session, and stream capture - they were solving a problem we are not going to have.

The actual model

The A2A thread IS the conversation. Not a reflection of one.

• Jay posts from taOStalk -> the message lands on the bus.
• The agent reads the bus and replies to the bus.
• taOStalk renders the thread. That is the session.

There is nothing to keep in sync, because there is no second copy. The conversation has one home - the bus - rather than living in a CLI scrollback that dies with the process.

Why this is the right call

It removes a dependency class instead of managing one. A pty-based mirror needs tmux or an equivalent on every machine, breaks differently on macOS, Linux and Windows, and couples us to how each CLI happens to render. Bus participation needs an HTTP client and nothing else. Any coding CLI on any OS can join by posting and reading - that is the harness-agnostic property Jay wanted, achieved by having fewer moving parts rather than more.

It already works. Messages posted to the bus reach a running agent today, and agents reply by posting back. This is not a thing to build; it is a thing to use.

What actually remains

1. Liveness / wake - an agent answers immediately while a session is running; with nothing running, a message waits. Already tracked as the native A2A agent loop with a wake trigger (tinyagentos.com: Postgres + Ory Kratos identity service (phase 3) #93). This is the only real gap.
2. Rendering - bus posts are plain text today; content blocks make agent replies read properly in taOStalk (the s1 renderer cards cover this).
3. Decisions in thread - W1 (tsk-4micka) and W2 (tsk-p75ial), already queued.

Rule for anyone building here

Do NOT add a component that captures, mirrors or replays a CLI session. If a design needs a terminal multiplexer, a pty, or knowledge of how a particular CLI draws its output, it is the wrong design. Agents talk on the bus.

[jaylfc]

JAY DECISION: all chat moves onto the taOSmd bus; taOSmd becomes a required dependency

Supersedes the two-store situation. Recorded here so no slice is built against the old assumption.

The decision: every conversation - human-to-agent, agent-to-agent, file handoffs - lives on the taOSmd A2A bus. taOSmd stops being a swappable default and becomes a required component of taOS; other memory systems may replace or complement parts of it, but it stays present, at minimum to power the bus.

Jay's reasoning, which is a product argument and a good one: a memory system that manages communications is a differentiator. Conversation records living natively inside memory is how humans work, and it makes audit and observability native rather than bolted on. I had recommended the opposite direction (unify on the taOS core store, serve the A2A wire format from taOS); his argument beats mine and this is the direction.

Consequent product rule, from Jay: users are expected to talk to their agents in taOStalk. A conversation held in a TUI never reaches memory, audit or observability, so it may as well not have happened. Agent onboarding at deploy time must teach this explicitly.

Prerequisite before any migration: authenticated identity on the bus

Not a follow-up, a gate. The bus currently performs no identity verification - I demonstrated it rather than asserting it, posting successfully as @definitely-not-me (message 1377 in general, mine, left in place since the bus is append-only).

That is tolerable for LAN agent coordination. It is not tolerable once human conversations live there, for a reason specific to this decision: those messages become memory. A forged message is not merely misleading in the moment - it becomes remembered history that agents later retrieve and act on. The audit trail is the product here, and a forgeable audit trail is worse than none.

Requested from @taOSmd-dev on the bus (msg 1378) along with three design questions: how content blocks ride on a message, whether existing chat history migrates, and whether the storage design assumes coordination-scale traffic rather than every-message-in-the-OS scale.

taOS-side work this implies

• taOStalk reads and writes bus threads instead of the core chat store (after identity lands).
• Agent deploy onboarding gains full A2A instructions.
• W1/W2 decisions-in-chat retarget to the unified store.
• The core chat store's existing conversations either migrate or become read-only history - pending @taOSmd-dev's answer.