For the past year I’ve been building AI agents, and shipping them inside Angular apps.

And every single time, the same thing happened: the backend got all the love, and the Angular frontend got the leftovers.

So we built Threadplane.

Threadplane is an open-source framework for building fullstack agentic applications with Angular. It connects your agent runtime — LangChain, LangGraph, anything that speaks AG-UI — to production-ready Angular surfaces: chat, streaming, tool progress, interrupts, durable threads, and generative UI. All of it expressed in Signals, dependency injection, and standalone components. The way Angular actually wants to be written.

Let me tell you why we built it, what’s in it, and how to try it this week.

tl;dr

  • Threadplane is an Angular-native framework for building agentic apps. The runtime adapters are MIT licensed.
  • It bridges LangChain / LangGraph and AG-UI backends into Angular Signals through one injectAgent() call.
  • Generative UI works through either Vercel’s json-render (a fixed, trusted component catalog) or Google’s A2UI (a portable declarative UI protocol) — rendered into your design system.
  • It’s a complete solution: messages, status, tool calls, interrupts, branching, thread persistence, and tests. Not just stream plumbing.
  • Grab it at threadplane.ai and on GitHub at cacheplane/angular-agent-framework.

Why build this at all?

Here’s the thing nobody says out loud about agentic apps in 2026.

The backend is the easy part now.

That’s not a dig — it’s a compliment to everyone who’s done the work. LangChain and LangGraph give you orchestration, tools, memory, and human-in-the-loop. Protocols like AG-UI standardize how an agent streams events to a UI. The runtime layer has matured fast.

The frontend is where it still gets messy.

An agent isn’t a request and a response. It’s a stream. Tokens arrive a few at a time. A tool starts running, then finishes. The agent pauses to ask you to approve something. A subagent spins up, does its work, and reports back. The user edits an earlier message and the whole conversation branches. Then they close the tab, come back tomorrow, and expect the thread to still be there.

Every one of those is a frontend state problem. And in Angular, you were on your own.

For me, this came to a head on a flight-planning assistant I was building — an orchestrator agent delegating to research subagents, each grounded by retrieval over a different corpus. The agent architecture was right. The model choices were right. But wiring the stream into the Angular UI meant hand-rolling the same plumbing over and over: a service holding streaming state, a pile of BehaviorSubjects, manual change detection, and a tool-call lifecycle I kept reinventing in slightly different ways across components.

I’d written that code three times. That’s usually my signal that it shouldn’t be my code anymore.

The React teams already had this

Let’s be honest about the landscape, because it’s the whole reason Threadplane exists.

If you build agentic UIs in React, you’ve had good tools for a while. LangGraph’s official frontend integration, useStream, is a single React hook that gives you thread management, message streaming, and branching out of the box. There’s a mature ecosystem of generative-UI libraries. The examples, the starters, the blog posts — they assume React.

If you build in Angular, none of that was yours.

useStream is React-only. Most of the generative-UI libraries ship React renderers first, and Angular eventually, or not at all. So Angular teams did what Angular teams have always done: translate. Read the React example, mentally port the hooks to services, port the JSX to templates, port the React state to Signals, and hope you got the streaming edge cases right.

I don’t think that’s good enough anymore.

Angular has Signals. It has dependency injection that’s genuinely best-in-class for this kind of problem. It has standalone components and a strong opinion about structure. An agent UI built for Angular should feel like Angular — not like a React app wearing a trench coat.

That’s the gap. Threadplane is our attempt to close it.

What Threadplane actually gives you

Threadplane is a small set of focused packages. You take what you need.

The center of it is injectAgent(). Think of it as the Angular equivalent of useStream — but projected through Angular’s reactivity model instead of React’s.

You wire your backend up once:

// app.config.ts
import { provideAgent } from '@threadplane/langgraph';

export const appConfig: ApplicationConfig = {
  providers: [
    provideAgent({
      apiUrl: 'https://your-langgraph-platform.com',
      assistantId: 'my-agent',
    }),
  ],
};

Then you inject it into any component and bind directly to it:

import { Component } from '@angular/core';
import { ChatComponent } from '@threadplane/chat';
import { injectAgent } from '@threadplane/langgraph';

@Component({
  selector: 'app-support-chat',
  imports: [ChatComponent],
  template: `
    <chat [agent]="chat" />

    @if (chat.isLoading()) {
      <span>Streaming…</span>
    }
  `,
})
export class SupportChatComponent {
  protected readonly chat = injectAgent();
}

chat.messages(), chat.status(), chat.toolCalls(), chat.interrupt() — these are all Angular Signals. You bind them straight into your template. No subscriptions. No async pipe. No zone.js required.

And it’s not just the happy path. You get the stuff that actually makes an agent UI production-ready:

  • Streaming messages and status as reactive primitives.
  • Tool call progress — render what the agent is doing as it does it.
  • Interrupts for human-in-the-loop — pause, ask the user to approve, resume.
  • Subagents — a map of the subagents spun up during a run, so you can show delegation as it happens.
  • Branching and history — edit a message, fork the conversation, walk back through it.
  • Durable threads — persist a conversation and switch back to it later.
  • regenerate() and reload() for the retry behaviors users now expect.

That’s what I mean by complete solution. The boring, necessary 80% is in the box.

Bring your own runtime

Here’s a design decision I care about: Threadplane doesn’t want to own your agent.

We are not a backend agent runtime. Keep LangGraph. Keep your custom service. Keep whatever you’ve already invested in.

Threadplane talks to it through adapters:

  • @threadplane/langgraph adapts a LangGraph Platform endpoint into Angular Signals. This is the provideAgent() / injectAgent() pair above.
  • @threadplane/ag-ui bridges any AG-UI-compatible backend into the same chat surface.

AG-UI, if you haven’t run into it yet, is an open, lightweight, event-based protocol for connecting agents to user-facing apps. It’s a small set of typed events — message chunks, tool calls, state updates, lifecycle — streamed over SSE (or whatever transport you like). It’s being adopted across a lot of the ecosystem, which means an Angular adapter for it is leverage: speak AG-UI on the backend, and Threadplane renders it on the frontend.

The nice part is what sits between the adapter and the UI. Both adapters resolve to the same runtime-neutral Agent contract, and @threadplane/chat only ever consumes that contract. So swapping @threadplane/langgraph for @threadplane/ag-ui doesn’t touch your components or your templates. The seam is in one place, on purpose.

Generative UI, rendered into your design system

This is the part I’m most excited about, so let’s slow down here.

Generative UI is when the agent doesn’t just send text — it sends interface. A weather card instead of a paragraph about the weather. A form instead of “please reply with your address.” A chart instead of a table of numbers read aloud.

The scary version of this is letting a model emit arbitrary code into your app. That’s a fast way to move chaos across a trust boundary. For a real product, you don’t want that.

There are two good answers to this in 2026, and Threadplane supports both.

The first is Vercel’s json-render. The model generates JSON, constrained to a fixed catalog of components you define. The agent can only use the components you’ve approved — it can’t invent UI. @threadplane/render is an Angular engine built on @json-render/core that renders those JSON specs into real Angular components from your own library.

The second is Google’s A2UI — a framework-agnostic protocol for declaring UI intent, separating what the user should see from how it’s implemented. It’s the more dynamic, portable end of the spectrum. @threadplane/a2ui gives you the protocol types, a streaming parser, and a dynamic-value resolver in pure TypeScript.

Fixed catalog or portable protocol — that’s a real architectural choice, and it depends on your surface area. (I wrote a whole post on fixed versus dynamic schemas if you want to go deeper.) The point is that with Threadplane, both render into your design system. Approved components, your styles, your accessibility, your tests. The agent fills in the blanks. It doesn’t get to repaint the walls.

Why open source, and why MIT

We’re shipping this open source on purpose, and I want to be straight about exactly what that means.

The runtime adapters and the rendering engine — @threadplane/langgraph, @threadplane/ag-ui, @threadplane/render, and @threadplane/a2ui — are MIT licensed. Free for any use, including commercial, with attribution. The pieces that connect your agent to Angular and render generative UI are yours to use, fork, and build on.

The opinionated chat UI, @threadplane/chat, is the one exception: it’s free for noncommercial use and has a commercial license for production inside a for-profit company. I’d rather tell you that plainly now than surprise you in a LICENSE file later.

MIT for the foundation matters to me because of where this category is heading. The agentic frontend space is full of stacks that start open and quietly close, or that only really open up the framework everyone else uses. Angular teams — especially in fintech, healthcare, and other places where a React rewrite is off the table — deserve a foundation they can actually depend on. No required cloud. No app telemetry on by default. No bait-and-switch.

A quick, honest disclosure while we’re here: I also help maintain Hashbrown, an MIT-licensed framework for agents that run in the browser, for both Angular and React. People ask how the two relate, so — short version: Hashbrown is for browser-running, LLM-driven frontend agents. Threadplane is for production chat and generative UI on top of server-side runtimes like LangGraph and AG-UI. Different lanes. I’m genuinely glad both exist, and I think the Angular community is better off with more open tools in it, not fewer. 💚

Try it this week

That’s the pitch. Here’s the part where you go build something.

Install the LangGraph adapter and the chat UI:

npm install @threadplane/langgraph @threadplane/chat

Wire provideAgent(), drop in <chat>, and you’ve got a streaming agent UI in about thirty seconds. From there, add interrupts when you need a human in the loop, add generative UI when text isn’t enough, and swap to the AG-UI adapter if that’s your backend.

If you’re building agents in Angular, I’d love to know what you ship — and what’s still missing. Open an issue, tell me where it falls short, or just tell me it saved you from writing that streaming service a fourth time.

Let’s give Angular the agent frontend it deserves.