Suggestion for a vision of shared agent infrastructure

[brennancheung]

[Discussion] Extracting reusable primitives from t3code—toward shared agent infrastructure

Hey t3code team—I've been following your work and spent some time reading through the codebase. I'm exploring building something in the same space and wanted to share some thoughts on where I think the broader ecosystem could go. This is meant as a conversation starter, not a critique—you've built something genuinely impressive and I think there's an opportunity to make it even more impactful.

What you've built that I really admire

After reading through the repo, a few things stood out as particularly well-designed:

The Thread + Turn model. Separating the persistent conversation (Thread) from individual execution cycles (Turn) is the right abstraction. The OrchestrationLatestTurn with { turnId, state, requestedAt, startedAt, completedAt } is clean and gives you natural checkpoint boundaries without over-engineering the session concept.

The activity log abstraction. OrchestrationThreadActivity with { tone, kind, summary, payload } is a genuinely elegant design. The tone field ("info" | "tool" | "approval" | "error") gives instant semantic categorization without consumers needing to understand the underlying event taxonomy. The pure derivation functions in session-logic.ts—derivePendingApprovals(), deriveWorkLogEntries(), isLatestTurnSettled()—are exactly the right pattern: pure functions over an event log, testable without infrastructure.

The event-sourced orchestration engine. The full pipeline—OrchestrationCommand through the decider, into the append-only event store, through projectors to materialized read models, broadcast to WebSocket clients—is textbook event sourcing done well. The OrchestrationEvent schema with aggregateKind + type + payload and the sequence-numbered catch-up protocol (replayEvents(fromSequenceExclusive)) solve real problems around client reconnection and state consistency.

The provider adapter pattern. The ProviderAdapter interface with startSession, sendTurn, interruptTurn is provider-agnostic by design. And the Codex adapter (CodexAdapter.ts) is, as far as I can tell, the only open-source Codex app server client implementation in existence. That's genuinely valuable work.

The status pill system. Four states, color + pulse encoding, unread detection via simple timestamp comparison (completedAt > lastVisitedAt). Minimal and it works.

The silo problem

Here's what I keep running into as I think about this space: all of this excellent infrastructure is locked inside the application.

If someone wants to build a mobile client for agent sessions, they have to rebuild the orchestration engine, the event store, the provider adapter, and the state derivation logic from scratch. If someone wants a different attention model—say, a global inbox sorted by urgency instead of a project-scoped sidebar—they have to fork the entire app. If an observability tool wants to consume agent session events, it needs a custom integration specifically for t3code.

The hard work—the Turn model, the event normalization, the provider abstraction, the derivation functions—is trapped inside one application's dependency tree. And every team building agent tooling is independently rebuilding these same primitives.

The OSI model for agent infrastructure

The framing I keep coming back to is the OSI networking model. OSI didn't just build a networking application—it defined a stack of layers, each with a clean interface, each independently swappable. You could swap out the physical layer (copper → fiber → WiFi) without touching the transport layer. You could build a new application protocol without rebuilding TCP. The layers gave the ecosystem the freedom to innovate at any level without starting from scratch.

I think agent infrastructure needs the same thing. Something like:

• Layer 1—Provider transport: raw communication with agent runtimes (Claude Code, Codex, OpenRouter, etc.)
• Layer 2—Turn execution: normalizing provider-specific events into a common Turn/Message model
• Layer 3—Session lifecycle: state machine, event store, interrupt/resume semantics
• Layer 4—Attention/observation: inbox, triage, prioritization, notification signals
• Layer 5—Integration surface: REST/WebSocket APIs, typed clients, CLI
• Layer 6—UI primitives: headless React hooks and components that speak the layers below

The key insight from OSI is that each layer only needs to know about the layer directly below and above it. A UI component at Layer 6 doesn't need to know whether the agent running at Layer 1 is Claude Code or Codex. An observability tool at Layer 4 doesn't need to know how sessions are transported.

Right now, t3code is essentially all six layers bundled into one application. That's fine for shipping—but it means anyone who wants to innovate at Layer 6 (a different UI) has to bring Layers 1–5 with them. And anyone who wants to contribute a Layer 1 implementation (a new agent runtime) has to integrate with the whole stack.

The M × N problem and the LSP analogy

This situation reminds me of what editors and programming languages looked like before LSP. Every editor had to implement language intelligence for every language. M editors × N languages meant M×N implementations. LSP collapsed that to M+N by standardizing the protocol between them.

The same M × N problem exists in agent infrastructure today: M UIs/orchestrators × N agent runtimes. t3code has excellent Codex support, and others are building Claude Code support, OpenRouter support, and more. But there's no shared interface—each integration is rebuilt from scratch for each combination. Observability tools need custom integrations for each runtime. Orchestration frameworks can't drive sessions generically.

A shared session event protocol—something like an "Agent Session Protocol"—could collapse this the same way LSP did. One provider adapter emits standard events; any consumer (UI, CLI, observability, orchestrator) can consume them without knowing which runtime is underneath.

The natural joints in agent execution are already converging toward common abstractions across independent implementations: session initialized, text streaming, tool started/completed, turn completed, approval requested, session ended. When independent projects arrive at the same abstractions, it's a signal those abstractions are right.

What could be extracted—concrete ideas

I'm not suggesting a big redesign. More like: what if the primitives that already exist in t3code were published as standalone packages—one per layer—that the broader ecosystem could build on independently?

Layer 1–2—packages/contracts + provider adapters as published packages.
Your contracts package is already cleanly separated. What if it (or a subset) were published under an ecosystem-neutral name? The OrchestrationEvent envelope, the OrchestrationThreadActivity shape, the Turn/Thread type definitions—these are useful to anyone building agent tooling. And the ProviderAdapter interface (startSession, sendTurn, interruptTurn) is generic enough that other projects could implement against it. Your Codex adapter is the reference implementation—publish it standalone and it becomes the go-to library for anyone integrating with Codex, not just t3code users.

Layer 3—The event-sourcing primitives as their own package.
The OrchestrationEventStore, the projection pipeline pattern, the replayEvents catch-up protocol—these are infrastructure that anyone building an agent session backend would want. Right now you have to take the whole server to get them.

Layer 4—The derivation functions as a shared utility.
derivePendingApprovals(), derivePendingUserInputs(), deriveWorkLogEntries(), isLatestTurnSettled()—pure functions with no infrastructure dependency, useful to anyone building agent session UIs regardless of which backend they use. A session-logic package would be immediately valuable to the ecosystem.

Layer 6—React UI components as headless primitives.
The sidebar, status pills, chat view—these represent real design decisions that others would benefit from. Published as headless components (logic separated from styling, which you're already doing with the .logic.ts pattern), they could be styled differently by different products while sharing the interaction patterns. Think Radix UI for agent session UIs.

A question, not a proposal

I might be missing context on why things are structured the way they are—there are always tradeoffs that aren't visible from reading code. But I wanted to put the idea out there:

What if t3code's biggest impact isn't the application itself, but the infrastructure primitives it proves out?

The application is great. But the Turn model, the event normalization, the provider abstraction, the derivation patterns—those could be the foundation that an entire ecosystem builds on. Like how React's component model became bigger than Facebook's use of it, or how VS Code's LSP implementation became bigger than VS Code's language support.

I'd love to hear your thoughts on this. Are you already thinking along these lines? Are there reasons the current structure makes more sense that I'm not seeing? Would it be worth exploring what a shared event schema might look like across different implementations?

Happy to jump on a call or continue the discussion here. Either way, thanks for building in the open—the architecture decisions you've made are a valuable reference for anyone working in this space.

[Da1sypetals]

LLMs are developing so fast and I deem it too early to try to design a unified solution for agent sessions:

• After the market converges, there will not be too many labs training production-capable coding LLM because it is VERY EXPENSIVE. I guess this number will converge to 4~8 in the next few years. In this scale, M+N is not significantly smaller than MxN.
• Until that day of convergence, LLM provider will keep experimenting on new ways for LLMs to manipulate a computer. An app is fine to this frequent changes (especially with the help of today's coding agents) while a protocol is built for (relative) stability and cannot tolerate this kind of changes.

[brennancheung]

The proposal is less about trying to accelerate convergence for LLM providers specifically and more about the projects that want to build on top of agent sessions: desktop clients, web UIs, CLIs, IDE integrations, observability dashboards, and orchestration frameworks. For anyone who has an idea for a new UX pattern or multi-agent orchestration pattern they want to try, the barrier is enormous. Right now they are forced to build the entire stack from scratch or fork this repo just to experiment. If the layers were already extracted and could be pulled in as packages, that would dramatically lower the barrier and encourage a lot more experimentation and innovation in the community.

When the infrastructure is divided up into layers, people can focus and build higher quality implementations of just that layer, and that benefits everyone. For example, React components for rendering the chat sessions that someone spent a lot of time making the design look great. Agentic engineers don't tend to be the best designers—nor do they want to be, so you tend to get projects where the chat sessions are just terminal or really bad looking.

Also, to clarify, the instability in the provider landscape is actually why we need this. jQuery wasn't created after browsers standardized. It was created because of the incompatibilities between browsers. It gave developers a stable surface to build on while the underlying chaos sorted itself out. The same logic applies here. That's exactly when a shared abstraction layer is most valuable. It absorbs the churn so every project building on top doesn't have to.

Convergence isn't really a prerequisite for any of this. Realistically I think just covering Codex, Claude Code, and maybe something for local LLMs provides 90% of what builders will want to target. And if someone wants to target a less popular LLM, then it makes it easier for them to integrate that as well.

Right now, people building agentic solutions end up in one of two places. Either they cobble together their own ad hoc stack where the one thing they care about works but everything else is half baked (poor UX, brittle, buggy). Or they build a full application and end up locking users into their way of doing things. What if someone wants something slightly different? Shared layers would let people focus on the thing that makes their project unique without cutting corners on everything else.

Personally, I'm trying to experiment with some UX ideas around multi-session attention management and multi-agent orchestration patterns (like having agents observe and create higher level semantic annotations of other agents' sessions in real time and surface that in the UX). Things like CLAUDE.md markdown files and skills get you pretty far for single session workflows, but they are insufficient for the kind of cross-session coordination and observability I want to explore. I'm building my own session lifecycle, event normalization, and state management layers from scratch just to get to the point where I can even begin experimenting with the ideas I actually care about. That's a lot of infrastructure work before I can even start to test a single UX hypothesis. As of right now, I'm still building the lower layers. If the foundational layers already existed as packages and servers, I could jump straight into building the ideas I have. Other agentic engineers are in similar situations. There's a lot of duplication of effort that doesn't need to exist.

[Da1sypetals]

What if there are some big feature that Claude code have and others just don't? How do you abstract that? This problem is significantly different from the jQuery-browser one.

Also "less popular LLM" does not exist. Today if you want to use LLM for serious work, you either use GPT, Claude, Gemini, where they have there own harness (for the definition of this word plz refer to this video ) or open source ones like Kimi, GLM, Qwen, which are trained to be plugged into one of the harnesses provided above. If a company train coding-capable LLM, which cost them hundreds of millions of dollars, it is almost sure that they can (and want to) afford the cost to maintain its usability in tools using their LLM.

The speed of new coding-capable LLM provider emerging will never match 1/100 the speed new programming languages are made, or 1/100000 the speed new HTTP services are built. IMO protocols is just not needed here.

[zayenz]

I had a need of something like this recently, where it would be a point to integrate coding chat threads into another application. Doing that from scratch would be too messy to be worth it, but re-using the core infrastructure of T3 Code would be very nice.

A similarity is Ghostty, where the core library enables other projects like cmux. Having a libt3code that could be re-used by other systems would be really nice and could enable some really interesting projects.

[juliusmarminge]

This is a broad architectural discussion rather than a bounded change that can be implemented or verified as one issue. Concrete package extraction or protocol proposals should be filed separately with a defined consumer and compatibility surface.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.