DEV Community: Brian Love

LangGraph Subgraphs: When to Split a Graph and When Not To

Brian Love — Tue, 03 Nov 2026 16:00:41 +0000

Most people reach for a LangGraph subgraph expecting a state boundary, and what they actually get is an observable one.

If your question is "single agent, approval loop, or multi-agent?", that's an architecture question, and the decision matrix already answers it.
This post is about the layer underneath: what a subgraph actually changes at runtime, why our own graphs got split, and what the frontend sees while a child is running.

What does a subgraph actually give you?

Nested execution and namespaced stream events.
That's the whole list.

Let's start with the canonical pattern, which is small.
Compile a child StateGraph, then add the compiled graph as a node in the parent:

research_builder = StateGraph(MessagesState)
research_builder.add_node("search", search_web)
research_builder.add_edge(START, "search")
research_subgraph = research_builder.compile()

builder = StateGraph(MessagesState)
builder.add_node("research", research_subgraph)  # a compiled graph, used as a node

Two things change.
The child runs as its own graph, with its own nodes and its own step sequence, rather than being flattened into the parent's.
And LangGraph emits the child's stream events under a namespace, so a consumer can tell parent output from child output.

I think state isolation gets assumed as a third thing, and it shouldn't be.

If parent and child share MessagesState, the child appends to the same message list the parent is building.
Nothing about add_node fenced anything off.

Isolation is something you design.
Give the child its own state schema, then map in at the boundary and map the result back out.
That's a decision you make and maintain, not a property compile() hands you.

We ship one graph that does exactly that, and because it's a capability demo built to show the primitive, it's a clean look at the shape.
Its child state schema has no messages key at all.
Parent and child share exactly two keys, research_topic and research_brief, so the child is handed a topic and hands back a brief.
It can't read the transcript, and it can't append to one.

That boundary is real, and none of it came from compile().
It came from writing two TypedDicts and being deliberate about what they share.

What about context windows and error boundaries?

Those are real reasons to split (our own docs lean on them).
The subgraphs guide points at per-task context windows and failure containment as reasons to reach for subagents, and the docstring on our own research child's only node calls it "a focused contractor."

But let's look at where each one actually comes from.
A narrow context window is a consequence of what you pass into the child's ainvoke; you get it by handing over a topic instead of a transcript.
An error boundary is a consequence of how the parent handles a failed child call, and a node-level retry wraps any node, plain function or compiled graph alike.
Reuse across parents is a consequence of the child being a value you can reference twice.

You can have all three without ever compiling a child graph, and you can compile a child graph and get none of them.

There's one more, and it's worth stating because it looks like a counterexample.
Wire the child in as a node under a parent that has a checkpointer, and the child's steps get checkpointed under its namespace, which is what lets you interrupt and resume at child granularity.
That's the namespace again, doing a second job.

Why do people really split?

In our own repo, the honest answer is: so the frontend can see the delegation.

That's a claim about our own graphs, not a law of the framework (and one of them splits for a different reason entirely, which I'll get to).
But it's a natural experiment rather than a portfolio.
Nobody wrote these to prove a point about subgraphs, and the constraint that drove them, a frontend that renders per-child progress, isn't specific to us.

Here's the comment we wrote at the time, sitting above the research subagent in our canonical examples/chat graph:

# Research subagent — a small compiled child graph the parent dispatches
# via the `research` @tool. Running it as an actual subgraph (vs. inline
# logic) is what causes LangGraph to emit stream events under namespace
# prefix `tools:<id>` for the child run, which is what the @threadplane/langgraph
# SubagentTracker keys on to populate `agent.subagents()`.

That's not a state argument.
It's a visibility argument.

The design doc for that feature is blunter still.
Here's the alternative it rejected:

Plain `@tool` returning a synthesized "subagent" payload — Simpler graph
code but does not exercise the SubagentTracker code path: no `tools:`
namespace events get emitted because no subgraph runs. The card would
render empty. Rejected.

Our cockpit/chat/subagents demo makes the same call.
Its three specialists dispatch through a real compiled child graph because the subgraph run is what emits namespace events, and the namespace events are what the tracker turns into per-child progress.
Run the specialists as a flat in-process helper and the feature still works; the UI just can't see it working.

In both of those graphs the compiled child is invoked from inside a @tool body, not wired in as a plain node.
That's deliberate: the tool call carries the identity, an id the tracker can attribute the child's stream to, and a subagent_type to name it.

A plain add_node subgraph has an identity too, just a thinner one.
Its namespace segment is unique per invocation and prefixed with the node name, so it registers in subagents() under its namespace key the moment it first streams, named by its node.
The subgraph is what makes the events observable; the tool call upgrades that identity from a node name to a real delegation record, with arguments a UI can render.

What does the frontend see while a child runs?

Namespaced events, and nearly everything interesting downstream follows from that one fact.

What does the wire look like?

The event type carries the namespace after a pipe, so the base type is the part before it:

messages                 # parent
messages|tools:<uuid>    # a child run, streaming under its own namespace

Our transport requests those child streams by default: streamSubgraphs is true unless you turn it off.
That's the LangGraph JS SDK's own option name, passed straight through, and it's worth knowing if you're coming from the Python API, where the in-process graph.stream() equivalent is the subgraphs=True kwarg.

What's the terminal-event hazard?

A child graph terminates before the parent does, and a child's terminal event looks an awful lot like the parent's.

Without a namespace guard, that child terminal marker gets read as "the run finished" and closes out the parent's still-streaming assistant message.
We guard it by refusing namespaced events as top-level terminal evidence, and there's a test that feeds a namespaced terminal marker in and asserts the parent message settles with outcome interrupted rather than success.

If you ever write a transport against this stream yourself, that's the bug you'll hit, and it'll look like truncation rather than a namespace bug.

Where does child text go?

Onto the child's stream, and nowhere else.

Any consumer reading a namespaced stream has to decide what a child's tokens mean, and "append them like everything else" is the path of least resistance.
It's also a trap, and a well-hidden one.
Merge a child's tokens into the transcript and its internal notes render as their own chat bubble mid-stream.
Then the parent's final values event rewrites the message list from authoritative graph state, and the stray bubble disappears on its own.
The end state looks right.
The streaming pass didn't.

So we don't make it a decision at all.
A namespaced event belongs to its child, structurally: it feeds that child's messages() on the subagent stream and never merges into the parent transcript.
There's no opt-out flag because there's nothing to opt out of.
What the transcript shows at settle is decided by state: a shared messages key delivers the child's message through the final values sync, and an isolated child schema means it never arrives.
transcriptNodeNames still exists for the genuinely separate problem of top-level side-effect nodes, like routers and title generators.

How does a child get attributed?

By an announced binding, and for me this is the part of the design I'd steal for any protocol.

The tools:<uuid> namespace a child streams under is a checkpoint id, assigned independently of the parent's tool-call id.
Nothing on the wire links the two.
But the server knows both halves.
So the graph announces the pair: one custom event pairing the child's checkpoint namespace with its tool-call id, emitted from inside the tool body.
The tracker treats that binding as authoritative.
It never overrides an established mapping, it works with any number of children in flight, and it replays any chunks that streamed before the binding arrived.

There's also a description-comparison ladder for graphs that don't announce: exact match on the tool call's description argument, then substring either direction, then a positional fallback that only fires when exactly one unmapped subagent is still pending or running.
That last rung is deliberately conservative.
With parallel children in flight, guessing would cross-wire one card's output into another, so an unattributed stream stays buffered instead.
An empty card beats a confidently wrong one.

The general point is worth carrying to any protocol.
A consumer mapping child runs onto delegations is doing string matching unless something hands it an id.
Here the graph hands it one, which is why the ladder is a fallback, and why it would be load-bearing in a stack that can't announce.

Nesting is worth knowing about too.
A subagent that itself delegates gets its own entry in subagents(), keyed by its namespace path, the same way a plain subgraph node does.
Each level of delegation surfaces as its own stream; the map stays flat, so there's no parent/child tree to walk.

When should you not split?

When there's no observable boundary to draw and no genuinely divergent state.

The cleanest evidence I have is a control group we didn't set out to build.
Our cockpit/ag-ui/subagents capability ships the same three-subagent feature as the LangGraph one.
It's a LangGraph StateGraph too: same framework, same orchestrator-plus-task-tool shape, same three roles, same cards in the UI, with no subgraph anywhere.
Its module docstring says so outright:

Mirrors cockpit/chat/subagents' orchestrator + `task` tool + `_run_subagent`
structure, but each dispatch emits `subagent_activity` CUSTOM events [...]
The backend's SubagentEmittingAgent expands those CUSTOM events into the
protocol's standard SUBAGENT_STARTED / TEXT_MESSAGE_* (attributed via
subagentRunId) / SUBAGENT_FINISHED / SUBAGENT_ERROR events

The thing that differs is the transport.
AG-UI already carries first-class delegation events: SUBAGENT_STARTED, SUBAGENT_FINISHED, and content events attributed to a child run.
So the specialists stayed a flat async helper, the tool body dispatches its progress as custom events, and a thin wrapper on the server expands those into the protocol's standard subagent events on the wire.

The subgraph was never required by the feature.
It was required by the transport.

You could dispatch custom events from the LangGraph graph too.
Nothing stops you, and adispatch_custom_event is a LangChain primitive, not an AG-UI one.
What namespaces buy is that you don't have to.
The boundary emits its own identity for free, and a transport that reads it works against any graph rather than any graph that remembered to instrument itself.

Staying flat wasn't free.
There's no separate state schema to isolate anything into, and no child step sequence; every specialist gets the parent's shape, one LLM call wide.
What it bought was one fewer graph for a feature that renders identically.

For me, that's the test.
If your transport already has a way to say "a child is working right now," or your UI doesn't render per-child progress at all, then a subgraph is a boundary you now have to defend: an extra state schema, mapping at both edges, and one more place to look when a message goes missing.

And splitting because a region of the graph feels like a separate concern isn't a reason on its own.
A node is already a unit.

So when does a split earn itself?

When the child really is a different graph.
The repo has exactly one of those, and after arguing the other side this whole time, it's only fair to show it.

Our examples/ag-ui demo runs on that same AG-UI transport, and its research tool reaches the frontend the same way: the protocol's standard SUBAGENT_* events, with the child's messages and its own lookup tool call attributed to the child run.
So it isn't buying observability.
It already had it.
It compiles a child graph anyway.

Let's look at what the child is, though.
It has its own agent → tools → agent loop with conditional edges and an iteration cap: a different control flow from the parent's, not a slice of it.

This part took me a second read to see.
A custom child state schema doesn't discriminate at all: the two graphs I just used as observability evidence also define their own child TypedDicts.
But both of those children are one node and a straight line, so the schema is really just an argument list with a type on it.

So it's the control flow, not the schema.
A child that carries a topic string is a function call wearing a graph costume.
A child that loops until it's satisfied is a graph.

Conclusion

Split when something outside the graph needs to see the child run as its own thing: a card, a progress panel, per-child streaming.
Split when the child has its own control flow (a loop, a branch, a stopping condition the parent doesn't have) and you're willing to own the mapping at both edges.
Don't split for tidiness, and don't assume the split isolated state: wire a child in as a node on a shared MessagesState and it appends straight to the transcript the parent is building.

The architecture matrix covers the tiering question, the subgraphs guide has the composition and subagents() wiring, and What injectAgent() Actually Returns walks the signal surface those child streams land in.

If you've split a graph for a third reason (not observability, and not a child that's genuinely its own graph), please let me know.
Those are the two I've been able to justify, and I doubt they're the only two that exist. 🤔

AG-UI vs. WebMCP: Who Owns the Agent?

Brian Love — Thu, 29 Oct 2026 22:26:13 +0000

Learn the difference between AG-UI and WebMCP, and when you'd reach for each one.

Both show up in the same conversations, both mention tools, and both promise to connect agents to web apps.
So it's easy to assume they compete, but they actually point in opposite directions.
Once you see which way each one points, the choice gets simple.

Goals

Understand what AG-UI does.
Understand what WebMCP does.
Learn the one question that tells them apart.
See how they work together in the same app.
Learn where Threadplane fits.

What is AG-UI?

AG-UI is an open protocol for streaming an agent's work to a user interface.

Your frontend starts a run, and the agent streams back a sequence of typed events:

RUN_STARTED and RUN_FINISHED bracket the run.
TEXT_MESSAGE_START, TEXT_MESSAGE_CONTENT, and TEXT_MESSAGE_END stream the assistant's reply token by token.
TOOL_CALL_START, TOOL_CALL_ARGS, and TOOL_CALL_END show the agent calling tools as it happens.
STATE_SNAPSHOT and STATE_DELTA keep shared state in sync between the agent and the UI.

Over HTTP, that's a stream of server-sent events that looks something like this:

data: {"type":"RUN_STARTED","threadId":"t_1","runId":"r_1"}
data: {"type":"TEXT_MESSAGE_START","messageId":"m_1","role":"assistant"}
data: {"type":"TEXT_MESSAGE_CONTENT","messageId":"m_1","delta":"Checking flights"}
data: {"type":"TOOL_CALL_START","toolCallId":"c_1","toolCallName":"searchFlights"}
...
data: {"type":"RUN_FINISHED","threadId":"t_1","runId":"r_1"}

The important part is who is on each end.
On one end is your agent: a LangGraph graph, a Strands agent, a Mastra workflow, whatever you built.
On the other end is your UI, rendering those events as a chat, a timeline, an approval card, or a map.

AG-UI is the wire between two things you own.

What is WebMCP?

WebMCP is a proposed web API that lets a page expose tools to an AI agent running in the browser.

It's being incubated in the W3C Web Machine Learning Community Group, with editors from Microsoft and Google.
It's still a draft Community Group report, not a standard, and Chrome is running it as an origin trial.

The shape will feel familiar if you've built an MCP server.
You register a tool with a name, a description, a JSON Schema for its input, and an execute callback:

if ('modelContext' in document) {
  document.modelContext.registerTool({
    name: 'add_to_cart',
    description: 'Add a product to the shopping cart by SKU.',
    inputSchema: {
      type: 'object',
      properties: {
        sku: { type: 'string' },
        quantity: { type: 'number', minimum: 1 },
      },
      required: ['sku'],
    },
    annotations: { consequentialHint: true },
    async execute({ sku, quantity = 1 }) {
      await cart.add(sku, quantity);
      return `Added ${quantity} of ${sku}. Cart has ${cart.count()} items.`;
    },
  });
}

That execute callback runs in your page, with the user's session, cookies, and app state already in place.
The spec describes these pages as being similar to MCP servers that implement their tools in client-side script instead of on a backend.

Chrome also documents a declarative flavor in its origin trial, where you add toolname and tooldescription attributes to an existing <form> and the browser builds the tool from its fields.
That part isn't in the normative spec yet, so I'd treat it as experimental.

A quick heads up if you've read earlier tutorials: they use navigator.modelContext, while the current draft exposes the API on document.modelContext.
That's why I feature-detect rather than assume.

On one end of WebMCP is your page, offering tools.
On the other end is an agent you probably didn't build: the one built into the browser, or an extension, or something the user brought with them.

WebMCP is the doorway you open for someone else's agent.

So what's the difference?

Here's the one question I'd ask: who owns the agent?

If you own the agent and you're building the UI for it, that's AG-UI.
If the user brings the agent and you want your site to be usable by it, that's WebMCP.

Put another way, the arrows point in opposite directions:

	AG-UI	WebMCP
Who owns the agent?	You	The user, browser, or extension
Where does the agent run?	Usually your server	Usually the browser
What flows over it?	A stream of events: text, tool calls, state	Tool definitions and tool calls
Who renders the conversation?	Your app	The agent's own UI
What does your app provide?	The UI	The capabilities

For me, that last row is the clearest way to hold it.
With AG-UI, your app is the interface to an agent.
With WebMCP, your app is a set of capabilities that some other interface can drive.

Doesn't AG-UI have tools too?

It does, and this is where the confusion usually starts.

AG-UI supports frontend tools.
When you start a run, you can send a list of tool definitions along with the messages.
The agent can call them, the call streams down as TOOL_CALL_* events, your frontend executes it, and the result goes back on the next run.

So in both protocols, a tool can run in the browser.
The difference is still ownership.
AG-UI frontend tools are offered to your agent, as part of a conversation your app is hosting.
WebMCP tools are offered to whatever agent the browser lets in, and your app may never see the conversation at all.

I think of AG-UI frontend tools as private, and WebMCP tools as public.
That's a simplification, since WebMCP has origin controls and a Permissions Policy gate, but it's the right instinct for how carefully you should design them.

Can I use both?

Yes, and I think a lot of apps will.

The nice part is that the tool shapes are nearly the same: a name, a description, and a JSON Schema.
So you can write the capability once and offer it through both doors:

const addToCart = {
  name: 'add_to_cart',
  description: 'Add a product to the shopping cart by SKU.',
  inputSchema: {
    type: 'object',
    properties: { sku: { type: 'string' }, quantity: { type: 'number' } },
    required: ['sku'],
  },
  execute: async ({ sku, quantity = 1 }) => {
    await cart.add(sku, quantity);
    return `Added ${quantity} of ${sku}.`;
  },
};

// Door 1: your own in-app assistant, over AG-UI.
const tools = [{ name: addToCart.name, description: addToCart.description, parameters: addToCart.inputSchema }];

// Door 2: the user's browser agent, over WebMCP.
if ('modelContext' in document) {
  document.modelContext.registerTool(addToCart);
}

Your in-app assistant gets a rich, branded experience: streaming text, tool views, approvals, and state you control.
A user who prefers their own agent still gets a site that works with it, instead of one it has to guess its way through by reading the DOM.

If you're building that in-app assistant in Angular, the client tools guide shows the AG-UI side.

What should I watch out for?

A few tradeoffs worth keeping in mind:

WebMCP is early. It's an origin trial with a moving API surface. Feature-detect, and don't build a critical path on it yet.
You don't control the WebMCP caller. Treat every input as untrusted, keep inputs narrow, and mark anything that spends money or sends a message with consequentialHint. The user's agent may be reading content from other tabs, so prompt injection is a real concern.
AG-UI means you run the agent. That's infrastructure, model costs, and a backend to deploy. The upside is that you control the whole experience.
Neither one replaces the other. WebMCP doesn't stream your agent's reasoning into your UI, and AG-UI doesn't make your site usable by an agent you didn't build.

Where does Threadplane fit?

A few questions come up whenever I talk about this, so here are the short answers.

Why does Threadplane use AG-UI?

Threadplane is a UI library for agents you own, which is exactly the AG-UI side of the arrow.

AG-UI gives us one adapter that reaches a lot of runtimes.
@threadplane/ag-ui works with any backend that speaks the protocol: CrewAI, Mastra, Microsoft Agent Framework, AG2, Pydantic AI, AWS Strands, and LangGraph fronted by AG-UI.
We test that claim against real runtimes, and the results are in Choosing an adapter.

For me, that's the appeal.
Your Angular components shouldn't care which framework your agent team picked, and a protocol is how you keep it that way.

Why do we also use LangGraph directly?

@threadplane/langgraph talks to LangGraph Platform through LangGraph's own JavaScript SDK, without going through AG-UI.

The reason is durability.
Thread history, checkpoints, and time travel are things LangGraph does really well, and they're outside what the AG-UI protocol defines.
Going direct lets the LangGraph adapter expose history() and the rest of the thread surface, instead of only what fits through the event stream.

The tradeoff is a second adapter to maintain.
The upside is that you don't pay for it in your components: both adapters produce the same Agent contract, so <chat [agent]="agent" /> doesn't change when the import does.
I wrote up exactly what changes when the runtime changes if you want the details.

Does Threadplane support WebMCP?

No, not today.

Threadplane builds the UI for your own agent, and WebMCP is about exposing your page to someone else's.
Those are different jobs, so nothing about WebMCP is blocked by Threadplane, and nothing in Threadplane needs it.

If you want both, you can do it yourself today.
Offer a tool to your in-app agent through Threadplane's client tools, and register the same function with document.modelContext next to it.

Conclusion

In summary, AG-UI and WebMCP solve different problems.
AG-UI connects your agent to your UI with a stream of events.
WebMCP lets your page offer tools to someone else's agent running in the browser.

When you're not sure which one you need, ask who owns the agent.
The answer tells you which way the arrow points.

I'm really curious to see where WebMCP lands as it moves through the standards process.
If you're experimenting with either one, or both, let me know what you're building.

Three Questions to Answer Before You Ship an Agent UI

Brian Love — Wed, 16 Sep 2026 05:29:13 +0000

Most teams building an agent UI start with the chat box and work backwards.

I think that is the wrong order.

The decisions that shape the product are made earlier, usually by default, and usually without anyone noticing they were decisions.

In this post, I want to give the three I keep coming back to:

Where does the agent loop run?
How does the model hand you UI?
Which dimension did your tests delete?

I build in Angular and I maintain Threadplane, so my examples lean that way. The questions apply to any framework.

tl;dr

The agent loop runs in one of three places: a vendor's server, your route running a vendor's code, or your agent. Pick on purpose.
Generative UI is not one thing. The useful choice is between a fixed spec you validate up front and a live surface the agent keeps editing.
Every deterministic test harness buys determinism by deleting a dimension of the real system. Know which one yours deleted.

1. Where does the agent loop run?

The agent loop is the code that calls the model, sees a tool call, runs it, and calls the model again.

Where it lives decides who holds the API key, where approvals pause, where threads persist, and whose release schedule you are on.

I compared five libraries on this in September 2026. The answers sort into three shapes:

A vendor server in the request path. You deploy the library's runtime and your browser talks to it. You get key custody, auth, routing, and trusted middleware in one place. You trade a second server on the hot path.
Vendor code in your route. No box to deploy, but the loop is the library's, inside an API route you own. Approvals and persistence can be first-class because the library owns both ends. You trade a loop that is separate from the one your agent framework already has.
Your agent. The UI talks to the agent server directly. One loop, owned by the framework you already chose. You trade the ability to show anything the server does not send.

For me, the third shape is right for most teams, and it is the one Threadplane is built on.

If you are running an agent, you already have a server. It holds the model key, it already authenticates, and it already sees every tool call. A vendor's box in front of it is a second place to solve a problem you already had one place to solve.

That does not mean no server at all. Put an endpoint you own in front of your agent for auth and credentials. The difference from a vendor runtime is who owns the code running in it.

The full comparison, with every cell source-checked and the costs of my own choice listed, is in Why Do Agent UI Libraries Require a Runtime?

2. How does the model hand you UI?

"Generative UI" hides three mechanisms behind one phrase:

Tool-call rendering. The model calls a tool and you map the tool name to a component. Every library does this, and it is where most teams should start.
Declarative specs. The model authors a UI tree in a standard format and the client renders it from a catalog you registered. The two open specs gaining ground are A2UI and json-render.
Sandboxed apps. An MCP server returns a ui:// resource and the client mounts it in an iframe. This is MCP Apps, and my project does not render it yet.

The choice that matters is inside the second bucket, and it is about contract shape.

With a fixed spec like json-render, the contract is application-owned. You define the schema, validate the whole spec before it mounts, and your handlers decide what a click means.

With a live protocol like A2UI, the surface is agent-owned. The agent creates it, keeps editing it across turns, and receives structured actions back.

My heuristic is simple. If you can validate the entire UI before it renders, start with the fixed spec. If the surface has to live past its first render, step up to the protocol.

An order summary card is a fixed spec. A three-day itinerary that fills in prices and gets rewritten when the user objects is a live surface.

The walkthrough with the same card in both formats is in json-render vs A2UI.

3. Which dimension did your tests delete?

Agents are hard to test end to end because the model does not return the same thing twice.

The usual fix is to record its responses as fixtures and replay them. We test our whole demo fleet that way, and I recommend it. Two things about that setup deserve more thought than they get:

Where you put the mock decides what is under test. Mock at the app boundary and you have proven your component renders what you handed it. Mock at the model provider, with the real agent server running against a fake model endpoint, and your routing, streaming, and tool round-trips are all under test.
Every deterministic harness deletes a dimension. Ours deletes time. Replayed responses arrive in one or two chunks instead of token by token, so final-DOM assertions stay stable. A handful of fixtures opt back in with tiny chunks where the progressive render is the thing under test.

Here is the bug class that disappears when you delete time. A child agent streams tokens, a client merges them into the transcript as an extra bubble, and then the run settles and the transcript is rebuilt correctly. Assert on the finished DOM and the test passes. Any assertion after an await sees a settled system, and a self-correcting bug is one that settles.

So the question about your harness is not whether it is green. It is which dimension you deleted, and which tests opted back in.

The full accounting is in What Fixture Replay Can't Catch.

Conclusion

Each of these questions has a default answer that arrives with whatever library you install first. None of the defaults is wrong, but all of them are decisions, and I think you should make them as decisions.

For me: run the loop in the agent with an endpoint you own in front of it, start with a fixed UI spec and step up per surface, and mock at the model provider while knowing what you gave up.

Those are the answers Threadplane is built around. If you are building the same thing in another framework, I would like to hear where yours landed.

Bringing Agents to the Web with Angular: Announcing Threadplane

Brian Love — Thu, 04 Jun 2026 17:38:50 +0000

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.ai. 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 https://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.

The docs, quickstarts, and live demos are at threadplane.ai.
The code is on GitHub at cacheplane/angular-agent-framework.

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.

Agentic Memory and What It Means for Web Apps

Brian Love — Wed, 18 Mar 2026 23:02:39 +0000

Memory is becoming one of the most important design surfaces in agentic software.

Not because models suddenly became databases.
And not because storing more transcripts is the same thing as making a system smarter.

It matters because memory changes what kind of software we are building.

A stateless LLM can answer.
A system with agentic memory can improve.

That is a different class of product.

For me, the core idea is simple:

memory turns LLMs from stateless responders into stateful systems
memory is a form of non-parametric learning
the hard problem is no longer storing more context
the hard problem is deciding what should be remembered, when, and in what form

If you are building fullstack agentic web applications, this is the shift to pay attention to.

tl;dr

Agentic memory is not just retrieval. It is an agent capability to store, retrieve, update, summarize, and delete knowledge over time.
This gives us a practical form of continual learning without fine-tuning model weights.
For web apps, memory changes architecture, not just prompting. It affects UX, data modeling, evaluation, governance, and trust.
The right production model is usually typed memory, selective retrieval, background consolidation, and immutable raw history behind derived memory.
Memory is becoming an agent policy surface. That means memory quality will matter as much as model quality.

Angular Agent Framework

Check out threadplane - Agent UI for Angular at threadplane.ai for building agentic fullstack Angular applications using LangChain.

Why memory changes everything

Most LLM applications started as stateless request-response systems.

That was fine for summarization, classification, and one-shot chat.
It is not enough for software that is supposed to improve over time.

As soon as you want an agent to:

remember user preferences
reuse successful workflows
avoid repeated failures
carry state across sessions
personalize behavior without retraining

you need memory.

And not memory in the casual sense of "we saved the conversation somewhere."

You need a system where the agent can actively manage what it knows.

That is what makes the memory agentic.

What agentic memory actually is

Agentic memory is a system where an agent can decide to:

store something
retrieve something
update something
summarize something
delete something

That last point matters.
If the system can only append, it does not really have memory discipline.
It has a log.

This is why I think the right framing is:

Memory is not storage. It is a control surface for reasoning.

That is the real shift.

Agentic memory is like cramming for a test

One of the more important ideas here is that memory gives us a form of continual learning without changing model weights.

The model does not need to be fine-tuned every time it learns something useful.
It can improve by pulling the right memories into context at inference time.

That is why I think of memory as test-time learning.

Different systems approach it differently, but the common idea is the same:
the agent gets better because it can reuse abstractions learned from prior experience.

That is a much more practical path for product teams than constant retraining.

The three memory types that matter

I think it is useful to separate memory into three buckets:

Semantic memory
Episodic memory
Procedural memory

1. Semantic memory

Semantic memory is facts, preferences, constraints, and stable knowledge.

Examples:

preferred output format
user role
account rules
domain terminology
known business constraints

This is the memory type that drives correctness and personalization.

2. Episodic memory

Episodic memory is past experiences.

Examples:

a successful prior resolution for a similar support issue
a failed workflow and the correction that fixed it
a previous user interaction pattern

This is the memory type that helps reasoning by analogy.
It is how agents get a practical form of "I have seen something like this before."

3. Procedural memory

Procedural memory is behavior.

Examples:

preferred prompts
tool-use patterns
routing rules
safety policies
execution instructions

This is the memory type that improves consistency.

I think this separation matters because different memory types want different storage, retrieval, and evaluation strategies.

If you flatten them all into one vector store, you are usually making retrieval worse.

What this means for web apps

This is the part I care about most.

Agentic memory is not just an infra feature for backend agents.
It changes how web apps should be designed.

A web app with agentic memory is not just rendering model output.
It is participating in a learning loop.

The frontend becomes the place where memory is created, corrected, and validated.

That has a few practical implications.

1. Web apps become memory surfaces

The frontend sees things the model and backend often do not:

what the user accepted
what they edited
what they rejected
how long they hesitated
where they retried
when they abandoned

Those are memory candidates.

Not all of them should be stored.
But the web app is where those signals become visible.

2. Personalization becomes a first-class product system

Personalization used to mean feature flags, settings, and saved preferences.

Now it also means memory.

The agent should be able to remember:

how a person likes information presented
what defaults they repeatedly choose
what kinds of actions they permit or avoid
what vocabulary is normal in their context

That is a better product experience.
It is also a new governance problem.

3. Multi-session coherence becomes a UX expectation

Once users see an agent remember important context, they start expecting continuity.

That means the web app needs to help answer questions like:

what should persist across sessions?
what should expire?
what should be editable by the user?
what should be visible as remembered state?

This is why memory is also a UX problem, not just a systems problem.

4. Context engineering becomes product infrastructure

I think "context engineering" is one of the most useful phrases in this space.

The problem is no longer just fitting more tokens into a prompt.
The problem is selecting the right abstractions.

Bad memory systems create:

context poisoning
distraction
token waste
conflicting guidance
brittle personalization

Good memory systems do the opposite:

selective retrieval
summarization
distillation
isolation by scope
time-aware filtering

This is why I would argue:

The problem is no longer remembering more. It is remembering the right abstractions.

Reflection is where memory becomes learning

One of the most important loops in agent systems is:

act
observe
critique
store
reuse

That is reflection.

In practice, a lot of the gains in agent quality come from this loop.
The agent does something, observes success or failure, stores the useful lesson, and applies it later.

This is why grounded reflection matters so much.
If the critique comes from real environment feedback, user behavior, or verifiable outcomes, the memory is much more useful than a purely self-generated summary.

This is also why the web app matters so much.
It is often the best place to observe the real outcome.

The architecture I would actually ship

If I were building agentic memory into a web app today, I would not start with one giant memory store.

I would use a layered design:

Short-term thread memory
Long-term typed memory
Immutable raw history
Background consolidation

Short-term thread memory

This is the active working set for the current task or session.

Use it for:

recent messages
in-progress tool state
temporary planning context
current UI state

This is hot memory.
Fast in, fast out.

Long-term typed memory

This is where semantic, episodic, and procedural memories live separately.

Use it for:

user preferences
reusable examples
learned task heuristics
stable operating policies

This is where I want stronger structure and stronger retrieval rules.

Immutable raw history

Never trust repeated summarization as your only source of truth.

Summaries drift.
Compression loses nuance.
Derived memory can get subtly wrong over time.

So I want a raw, immutable log behind the optimized memory layer.

That gives me:

auditability
rollback
better debugging
safer reprocessing

Background consolidation

Not every memory write should happen synchronously in the request path.

Some should.
Others should be consolidated later.

That is the hot + cold model:

synchronous writes for critical immediate context
asynchronous consolidation for summarization, distillation, and indexing

That is usually the right tradeoff between latency and memory quality.

Patterns I like

There are a few patterns here that I think are especially practical.

Hot + cold memory

Write immediately when the task needs it.
Consolidate later when quality matters more than latency.

Distilled memory

Do not store raw transcripts as the primary memory object if what you really need is a reusable abstraction.

Store:

the lesson
the source
the timestamp
the confidence
the scope

That is much more useful than dumping an entire conversation into retrieval.

Immutable + derived memory

I trust systems more when they keep both:

immutable raw events
derived summaries and optimized memories

That is how you keep memory systems from becoming opaque.

Memory graphs

Similarity search is useful, but it is not enough.

Some memories are connected by:

causality
sequence
dependency
contradiction

Graph-shaped memory is much better at expressing that than naive top-k vector retrieval.

I expect more systems to move in this direction.

The production risks are real

Memory makes systems better.
It also makes them more dangerous.

At least four risks matter immediately.

1. Retrieval quality

Just because something is semantically similar does not mean it is operationally relevant.

Memory retrieval often misses:

causal relevance
implicit constraints
temporal change
contradictory updates

This is why memory quality is usually more important than memory volume.

2. Memory drift

If you repeatedly summarize summaries, you eventually distort the original meaning.

That is why derived memory needs provenance and raw backing data.

3. Security

Memory injection is a real design concern.

If an attacker can poison memory, they can shape future agent behavior.

This means memory systems need:

validation
trust boundaries
scoped access
deletion paths
source attribution

4. Evaluation

A memory system can look impressive in a demo and still fail long-horizon tasks in production.

We still need better evaluation for:

multi-session behavior
long-horizon execution
memory usefulness over time
robustness to stale or conflicting memories

Memory governance is now part of application architecture

This is the part I think teams will underestimate.

As soon as memory affects behavior, governance matters.

You need clear rules for:

what gets stored
who can access it
how it decays
how it is corrected
how it is deleted
how it is explained to the user

This is true for enterprise software.
It is even more true for consumer software.

The best systems will not just remember well.
They will remember responsibly.

My practical recommendations

If you are building agentic memory into a web app now, this is the sequence I would use:

Separate semantic, episodic, and procedural memory.
Keep immutable raw history behind derived memory.
Prefer distilled memory objects over raw transcript retrieval.
Add time, source, scope, and version to every stored memory.
Use synchronous writes sparingly and background consolidation aggressively.
Tune retrieval strategy by memory type instead of using one global approach.
Evaluate on multi-session and long-horizon tasks, not only single-turn quality.

That is the difference between "we added memory" and "we built a memory system."

Closing

Agentic memory changes the role of the model.
It also changes the role of the web app.

The web app is no longer just a place where model output gets rendered.
It is where memory is shaped, corrected, surfaced, and governed.

That is why I think memory is going to become foundational to intelligent software.

Not because remembering more is inherently better.
But because the right memory architecture lets software learn without pretending every improvement requires retraining.

Memory is becoming policy.
And policy is becoming product behavior.

That is what makes this interesting.

Google A2UI: Fixed Schemas, Dynamic Schemas, and a Safe Fallback Strategy

Brian Love — Wed, 18 Mar 2026 23:02:39 +0000

Google's A2UI is one of the more interesting protocol ideas in agentic UI right now.

Not because it lets a model generate arbitrary frontend code.
That would be a fast way to move chaos across a trust boundary.

It is interesting because it does the opposite.

A2UI gives the agent a declarative way to describe UI while keeping rendering inside a trusted client-owned component system.

That is the part that matters.
Especially if you are building a real product instead of a demo.

The practical question is not whether A2UI is good.
The practical question is how to use it without turning your UI contract into a probabilistic event.

For me, that comes down to one decision:

Fixed schema
Dynamic schema

My recommendation is simple:

Use fixed schemas by default.
Use dynamic schema overlays for the long tail.
Validate everything.
Retry a few times.
Fall back deterministically.

tl;dr

A2UI is a protocol for agent-driven interfaces where the client owns rendering and the model emits declarative UI messages.
A2UI v0.9 is more model-friendly than earlier versions because it is flatter, more prompt-friendly, and easier to validate.
Most teams should start with fixed schemas because they are easier to test, easier to operate, and easier to trust.
Dynamic schemas are useful, but only when they stay grounded in renderer-approved catalogs.
The right production posture is fixed by default, dynamic overlays for the long tail, and deterministic fallback when validation fails.

The Angular Fullstack Agentic Frameowork

Be sure to check out the Angular Agent Framework for building fullstack agentic applications using Angular. A2UI support will be landing soon!

Fullstack architecture sketch

Before getting into fixed versus dynamic schema, this is the deployment shape I would use:

Web Client
  - trusted A2UI renderer
  - advertises supported catalogs
  - may advertise inline catalogs
  - sends actions and data model updates

API / Agent Backend
  - receives client capabilities
  - selects fixed vs dynamic policy
  - builds prompt from selected catalog
  - runs schema repair loop when dynamic
  - validates final payloads
  - streams safe A2UI messages to client

Observability
  - schema validation failures
  - payload validation failures
  - fallback frequency
  - per-intent success rate

Why A2UI matters

A2UI matters because it gives us a cleaner split between model behavior and frontend control.

The model decides what interface should appear.
The client decides how that interface is rendered.

That is a much better contract than shipping arbitrary frontend code across the wire and pretending the security story will work itself out.

Why v0.9 is the interesting version

One caveat up front:
A2UI v0.9 is still a draft, while v0.8 is the stable production release.

So this is not a "ship and forget" protocol.
You should pin versions and test contracts carefully.

But v0.9 is still the version I would watch, because it is the version that feels much more usable for agent systems.

The notable shifts are:

a prompt-first design
createSurface replacing beginRendering
a flat component model with a component discriminator
more standardized updateDataModel
swappable catalogs instead of a single hardwired shape

That makes the protocol easier to prompt, easier to generate, and easier to validate.
That is the real win.

A quick note on what "schema" means here

When people say "fixed schema" or "dynamic schema" in the context of A2UI, they usually mean something looser than a single JSON Schema file.

In practice, the protocol is made up of separate artifacts:

a server-to-client envelope
shared common types
one or more catalogs that define renderable components

So the real decision is usually this:

do you give the model a fixed catalog contract?
or do you dynamically select, narrow, or extend that contract for a specific request?

That is the framing that matters.

The protocol shape you are actually building around

For a web app, the v0.9 lifecycle is fairly straightforward:

The server sends createSurface.
The server sends updateComponents.
The server may send updateDataModel.
The client renders the surface and sends actions back.
The server continues streaming updates as needed.

A minimal shape looks like this:

[
  {
    "version": "v0.9",
    "createSurface": {
      "surfaceId": "signup",
      "catalogId": "https://a2ui.org/specification/v0_9/basic_catalog.json",
      "sendDataModel": true
    }
  },
  {
    "version": "v0.9",
    "updateComponents": {
      "surfaceId": "signup",
      "components": [
        {
          "id": "root",
          "component": "Column",
          "children": ["title", "email", "submit"]
        },
        {
          "id": "title",
          "component": "Text",
          "text": "# Create account"
        },
        {
          "id": "email",
          "component": "TextField",
          "label": "Email",
          "value": { "path": "/user/email" }
        },
        {
          "id": "submit_label",
          "component": "Text",
          "text": "Continue"
        },
        {
          "id": "submit",
          "component": "Button",
          "child": "submit_label",
          "action": {
            "event": {
              "name": "submitSignup"
            }
          }
        }
      ]
    }
  }
]

The important implementation detail is that A2UI uses a flat list of components linked by IDs.
That is a good choice because it is easier to emit, easier to diff, and easier to validate for:

duplicate IDs
missing root
dangling references
cycles
orphaned components

Those are exactly the boring details that determine whether a generative UI system survives contact with production.

Strategy 1: Fixed schema

Fixed schema means your application chooses the catalog ahead of time and the model only emits valid instances of UI that conform to that contract.

This is the default I would recommend for most teams.

Use it when:

the workflow is business-critical
the UI shape is predictable
you want strong testability
analytics and event handling need to stay stable
you do not want renderer behavior drifting between requests

Examples:

onboarding flows
support triage
approvals
payments
account management
healthcare or compliance-heavy forms

These are not the places where you want model creativity.

Why fixed schema works

A fixed schema gives you a stable protocol boundary.
That buys you:

prompts are easier to reason about
examples are easier to curate
QA can build reusable fixtures
regressions are easier to reproduce
analytics stay more consistent
frontend behavior remains predictable

It also makes debugging much easier.
When something breaks, you are usually debugging a bad payload, not a drifting contract and a bad payload at the same time.

My rule of thumb

If the flow is revenue-critical, compliance-heavy, or operationally sensitive, start fixed.

You can always loosen the system later.
Going the other direction is usually painful.

Strategy 2: Dynamic schema

Dynamic schema is where things get more interesting.
It is also where teams get themselves into trouble.

What I mean by dynamic schema is not "let the model invent whatever UI primitives it wants."

That is not a schema strategy.
That is giving up.

In a production A2UI application, dynamic schema should still be renderer-owned.
The client needs to know how to render every component the model is allowed to reference.

So in practice, dynamic schema usually means one of three things:

Dynamic catalog selection from a trusted set
Dynamic use of client-advertised inline catalogs
Dynamic overlays that narrow or extend a trusted base catalog for a specific request

That third option is the one I would ship most often.

The dynamic pattern I recommend

Do not let the model generate a brand new universe from scratch.

Instead:

Start from a fixed trusted base catalog.
Let the model generate a task-shaped overlay.
Validate that overlay.
Merge it into the base contract for prompting and validation.
Fall back to the base contract if the overlay keeps failing.

This gives you flexibility without losing control.
Most products do not need unbounded UI generation.
They need a safe way to adapt a known renderer contract to the long tail.

Why validation is non-negotiable

A2UI v0.9 is more prompt-friendly.
It is not a security model.

If you allow a model to shape any part of the UI contract, then validation becomes part of the product, not an implementation detail.

At minimum, a serious pipeline should validate two things:

The schema contract itself
The final A2UI payload generated against that contract

That separation matters because a valid overlay does not guarantee a valid payload.

For dynamic schema in particular, I would validate:

overlay structure
component and property compatibility
child reference types
topology integrity
final payload instances against the selected catalog

Without this layer, dynamic schema quickly turns into "the backend forwards malformed intent and hopes the renderer is charitable."

The architecture I would actually ship

If I were building a fullstack agent web app around A2UI, this is the high-level policy I would use.

1. Fixed by default

Use a fixed catalog for the majority of flows.
Keep the happy path boring.

That is where stability and predictable UX come from.

2. Dynamic for the long tail

Use dynamic overlays only for workflows that are genuinely exploratory, tenant-specific, or too variable for one static prompt contract.

This keeps the flexible path available without making the whole system probabilistic.

3. Dynamic means task-shaped, not unbounded

Restrict dynamic behavior to things like:

narrowing allowed components
adding task-specific examples or constraints
selecting from trusted custom catalogs
merging safe overlays over a base catalog

Do not let the model invent component semantics the client never negotiated.

4. Validate, repair, retry, fallback

The loop should be:

Generate candidate overlay
Validate it
If invalid, feed the error back to the model
Retry a few times
Fall back to fixed if it still fails

I would cap retries at around five attempts.

Past that point, you are not repairing the schema.
You are negotiating with entropy.

At a high level, the control flow should look like this:

user request
  -> choose fixed or dynamic policy
  -> if dynamic:
       generate candidate overlay
       validate overlay
       if invalid:
         return validation error to model
         retry up to N times
       if still invalid:
         fall back to fixed catalog
  -> generate final A2UI payload
  -> validate final payload
  -> stream to client

The implementation should be just as explicit:

MAX_SCHEMA_ATTEMPTS = 5


def resolve_catalog(request_text: str, client_capabilities: dict | None):
    fixed_catalog = get_fixed_catalog(client_capabilities)

    if not should_use_dynamic_schema(request_text):
        return "fixed", fixed_catalog

    last_error = None
    last_overlay = None

    for _ in range(MAX_SCHEMA_ATTEMPTS):
        overlay = llm_generate_overlay(
            request_text=request_text,
            client_capabilities=client_capabilities,
            previous_error=last_error,
            broken_schema=last_overlay,
        )

        try:
            selected_catalog = validate_overlay(overlay, client_capabilities)
            return "dynamic", selected_catalog
        except Exception as exc:
            last_error = str(exc)
            last_overlay = overlay

    return "fallback-fixed", fixed_catalog

5. Validate the final payload too

Even after the schema contract passes, validate the generated A2UI payload before it reaches the client.

Schema validation and instance validation are separate responsibilities.
Treat them that way.

6. Cache successful overlays

If a task-shaped overlay validates and performs well for a repeated intent, cache it by tenant, task family, and capability set.

That reduces latency, prompt cost, and repeated schema thrash.

7. Treat all agent output as untrusted

This should be obvious, but it is still worth stating directly.

Agent messages, UI payloads, and model-shaped schema overlays are all untrusted input.

That means:

validation
sanitization
strict renderer boundaries
strong CSP and isolation where relevant
no casual trust just because the output happens to be JSON-shaped

A useful mental model

I think the cleanest way to reason about A2UI is this:

the renderer is trusted
the model is constrained
the backend is the enforcer
fallback is deterministic

That is the architecture.
Once you see it that way, the fixed-versus-dynamic decision gets much easier.

When to use which approach

My practical rule is simple.

Use fixed schema when you want reliability.
Use dynamic overlays when variability is real and the value justifies the complexity.

In practice:

fixed for core trusted workflows
dynamic for the long tail

Per surface, not per company.

Conclusion

A2UI v0.9 is a meaningful step forward for agent-driven interfaces.

The flatter structure, prompt-first posture, swappable catalogs, and explicit lifecycle make it much more usable than older "generate a giant nested object and pray" approaches.

But the big lesson is not that everything should become dynamic.
The big lesson is that agent-driven UI still needs architecture.

The posture I would use is:

fixed schemas for stable, high-confidence workflows
dynamic overlays for the long tail
strict validation in the middle
repair loops for recoverable failures
deterministic fallback when the model cannot produce a safe contract

That gives you flexibility without surrendering control.
And in agent systems, control is the thing that lets creativity survive production.

References

The Frontend Reward Loop for Agentic Software

Brian Love — Wed, 18 Mar 2026 23:02:37 +0000

I have been thinking about this after reading the rLLM work on post-training language agents.

The big idea in that work is right: if agents are going to improve, they need a loop.
Not just inference.
A loop of action, feedback, and improvement.

What I want to argue in this post is simple:

The frontend is the best place to collect the heuristics for that loop.
Most teams should push prompt augmentation much further before training an offline reward model.

tl;dr

Agent quality is now a feedback-loop problem, not only a model-size problem.
The frontend is the only place where intent, correction, and outcome are visible together.
Product heuristics can drive real gains without starting with offline reward-model training.
Prompt augmentation gets most teams very far on short and medium-horizon workflows.
Move to offline RL only when prompt gains flatten or long-horizon credit assignment becomes the bottleneck.

Fullstack Agentic Applications

Be sure to check out the Angular Agent Framework for building fullstack agentic applications.

From static intelligence to live behavior

Reasoning models can do very well on static tasks.
Agentic software lives in dynamic tasks.

That means we care less about one-shot correctness and more about behavioral quality over a sequence of steps:

Did the system choose a sensible next action?
Did the user need to undo or rewrite it?
Did the workflow actually complete?

This is why post-training agents matter.
And this is why product teams need to treat interaction data as first-class infrastructure.

Why the frontend is the best reward surface

The backend can tell us what was called.
The model logs can tell us what token came next.
Only the frontend can reliably tell us whether the user felt the action was useful.

The frontend gives us a dense stream of behavior signals:

Accept vs reject
Minor edit vs full rewrite
One-shot completion vs retry loops
Continue vs abandon
Agent flow vs human escalation

These are not perfect labels.
They are heuristics.
But they are high signal and available immediately.

In practice, this is the best early reward surface most teams have.

A practical heuristic set

If I were starting today, I would implement four buckets.

1. Correction heuristics

Edit distance between agent output and final submitted value
Undo/revert frequency after agent actions
Manual overwrite rate

2. Friction heuristics

Time-to-next-meaningful-action
Retry count for same intent
Dead-end path frequency

3. Outcome heuristics

Task completion rate
Reopen/regression rate
SLA-aware completion time

4. Trust heuristics

Delegation rate for repeat tasks
Human escalation rate
Opt-out after poor outcomes

No single metric is enough.
A composite score is usually better than betting on one proxy.

The part I want to challenge: do we need offline reward models first?

Usually, no.

I think most teams can get much further than expected with prompt augmentation before training a separate reward model offline.

When I say prompt augmentation, I mean the full runtime strategy:

Better task framing
Better context packing from recent user behavior
Better tool constraints and checks
Better fallback prompts for low-confidence cases
Better routing between prompt variants

This is still behavior optimization.
It is just inference-time optimization.

For many product workflows, that is enough to unlock most early gains.

How far prompt augmentation gets us

Prompt augmentation gets us very far on:

Bounded workflows
Clear completion criteria
Frequent user corrections
Fast evaluation loops

Examples:

Internal support triage
Structured drafting and form completion
Actionable summarization
Multi-step UI workflows with explicit completion states

Where it starts to fail:

Long trajectories with delayed outcomes
Heavy credit assignment ambiguity
High cost/latency from complex inference-time strategies
Persistent instability across prompt variants

That is when offline trajectory training and RL become worth the investment.

Recommended rollout

If you are building agentic product features now, this is the sequence I would use:

Instrument frontend interaction events with stable task/session IDs.
Define a small heuristic scorecard (correction, friction, outcome, trust).
Use that scorecard to drive prompt and routing updates weekly.
Build an eval flywheel with holdouts and regression checks.
Introduce offline reward-model training only after improvements plateau.

This keeps teams moving quickly while preserving a path to deeper optimization.

Guardrails

None of this works well without guardrails.

At minimum:

Privacy-safe event collection
Anti-gaming checks for proxy metrics
Correctness-weighted objectives (not just speed)
Human review samples to calibrate heuristic drift

If we do not add guardrails, we optimize the dashboard instead of the product.

Closing

The backend can train the policy.
But the frontend is where the reward signal is born.

If we want agents that improve from real human interaction, we need to treat frontend behavior as training infrastructure.

And we should be honest about sequencing:
Start with prompt augmentation.
Push it hard.
Then add offline RL when the data proves you need it.

Using Angular & LangChain together?

Check out the the Enterprise Streaming Resource for LangChain and Angular

References

rLLM: A Framework for Post-Training Language Agents
rLLM Docs: rLLM Project Documentation
Sutton and Silver: [Welcome to the Era of Experience](https://storage.googleapis.com/deepmind-media/Era-of-Experience%20/The%20Era%20of%20Experience%20Paper.pdf

The Landscape of Generative UI in 2026

Brian Love — Wed, 18 Mar 2026 23:02:36 +0000

Generative UI is no longer just "chat that can answer questions."

In 2026, it is a product and architecture decision.

In this post, I want to give a practical framework I keep coming back to:

Chat Components
Component Systems
Embedded Generative UI

tl;dr

Generative UI is a spectrum, not a single implementation pattern.
Each pattern optimizes for a different balance of control and flexibility.
Most teams should mix patterns by surface area, not pick one globally.

Why this matters now

The first wave of AI products proved that people will use chat interfaces.
The next wave is about execution: helping users actually complete work.

Text-only responses are often too slow for real workflows.
Users need affordances to compare options, edit inputs, and take action with confidence.

That is where Generative UI becomes useful: it converts intent into usable interface.

What Generative UI is

Generative UI is UI that is selected, composed, or embedded at runtime based on user intent and agent reasoning.

It is not "markdown in a chat bubble."
It is a system where:

the model interprets intent
tools fetch or mutate state
the UI renders clear actions and state transitions

What I'm working on.

Before we go any further, I'd love to share that I am building threadplane - Agent UI for Angular at threadplane.ai

The spectrum

I think about this as More Control -> More Freedom:

Chat Components
Component Systems
Embedded Generative UI

These are complementary patterns.
You can (and often should) use all three in one product.

1) Chat Components

Chat Components are predefined UI blocks that the agent can invoke.
The frontend team still owns the component implementation and behavior.

Why teams start here

Fastest path to a reliable production experience
Strong control over brand and behavior
Easier trust and security posture from explicit contracts

Tradeoffs

New UI shapes still require frontend releases
Less flexible for novel, long-tail requests

Best fit

Core, high-trust, brand-critical flows.

2) Component Systems

Component Systems use schema-driven composition.
The model or backend provides structured payloads, and the frontend composes the screen from reusable primitives.

Why this pattern scales

Lower coupling between backend behavior and frontend rendering
Better coverage for long-tail UI permutations
Consistent visual system even with many generated layouts

Tradeoffs

More engineering investment up front
Less pixel-perfect than handcrafted, one-off UI

Best fit

Enterprise and platform surfaces with broad variability and repeatable primitives.

3) Embedded Generative UI

Embedded Generative UI is when a host app embeds external app surfaces and coordinates secure handoff between agent context and embedded execution.

Why teams adopt it

Maximum flexibility for specialized experiences
Natural path to ecosystem or app-platform strategies

Tradeoffs

Hardest developer experience
Inconsistent presentation across embedded surfaces
More complex security and permission design

Best fit

Super-host products where extensibility is part of the core value proposition.

Where this is already being used (verified examples)

The examples below are based on public product/docs updates and are accurate as of February 21, 2026.

Chat Components examples

OpenAI's Spring Update (May 13, 2024) states ChatGPT users can "analyze data and create charts," which is a concrete case of model responses invoking visual components inside chat.
Salesforce announced Agentforce Cards (March 5, 2025), where agents embed Lightning Web Components in responses.
Intercom's Fin answer cards update (January 27, 2025) is another example of structured, reusable UI cards rendered inline in conversational responses.

Component Systems examples

Microsoft Copilot Studio documents Adaptive Cards as JSON-defined custom UI, including inputs and submit actions, rendered in chat surfaces.
Microsoft 365 Copilot API documents Adaptive Card response templates, including static and dynamic templates that map cleanly to schema-driven composition.
Salesforce's adaptive response formats (for example rich choice and rich link) show a standardized response schema approach for composing predictable UI affordances.

Embedded Generative UI examples

OpenAI's Apps SDK reference describes components rendered in ChatGPT and connected through a window.openai bridge, with explicit iframe and CSP controls.
OpenAI's ChatGPT apps lessons learned (February 4, 2026) notes they built roughly two dozen apps and discusses practical iframe architecture patterns for hosted app experiences.
OpenAI's Introducing GPTs (November 2023) and the GPT Store help article document the host + app-store model in ChatGPT.
Anthropic's Artifacts overview and Artifacts support docs describe interactive, side-panel app-like outputs embedded directly in the Claude host experience.

Getting started: Hashbrown

If you want to implement Generative UI in a web app today with Hashbrown, the core pattern is:

Stream model output from your backend.
Register renderable components in the frontend.
Use useUiChat so assistant messages can include UI trees, not just text.

The official setup in Hashbrown docs/README is:

Install @hashbrownai/{core,react,openai}.
Wrap your app with HashbrownProvider.
Define model-callable components with exposeComponent.
Use useUiChat({ components: [...] }) to render those components in assistant responses.

import { HashbrownProvider, exposeComponent, useUiChat } from "@hashbrownai/react";
import { s } from "@hashbrownai/core";

function App() {
  const { messages, sendMessage } = useUiChat({
    model: "gpt-4.1",
    system: "You are a helpful assistant that can render UI components.",
    components: [
      exposeComponent(FlightCard, {
        name: "FlightCard",
        description: "Show a flight option card",
        props: {
          airline: s.string("Airline name"),
          price: s.string("Formatted ticket price"),
        },
      }),
    ],
  });

  // render messages and call sendMessage(...)
}

export function Providers({ children }: { children: React.ReactNode }) {
  return <HashbrownProvider url="/api/chat">{children}</HashbrownProvider>;
}

References:

Getting started: CopilotKit (v2 APIs)

For CopilotKit, a practical v2 path is:

Use the root <CopilotKit> provider to connect to your runtime.
Use v2 chat components (for example CopilotChat or CopilotSidebar).
Register v2 frontend tools with useFrontendTool and a render function for in-chat UI.

import { CopilotKit } from "@copilotkit/react-core";
import {
  CopilotChat,
  ToolCallStatus,
  useFrontendTool,
} from "@copilotkit/react-core/v2";
import { z } from "zod";
import "@copilotkit/react-core/v2/styles.css";

function ToolUIs() {
  useFrontendTool({
    name: "showFlightCard",
    description: "Display a flight option card in the chat UI",
    parameters: z.object({
      airline: z.string(),
      price: z.string(),
    }),
    handler: async ({ airline, price }) => `${airline} ${price}`,
    render: ({ args, status }) => {
      if (status !== ToolCallStatus.Complete) return <div>Loading card...</div>;
      return <FlightCard airline={args.airline ?? ""} price={args.price ?? ""} />;
    },
  }, []);

  return null;
}

export default function Page() {
  return (
    <CopilotKit runtimeUrl="/api/copilotkit">
      <ToolUIs />
      <CopilotChat agentId="travel-agent" />
    </CopilotKit>
  );
}

Notes for v2:

Keep hooks/components from @copilotkit/react-core/v2.
Import the provider from @copilotkit/react-core (as the v2 docs specify).
Use Zod schemas for v2 tool parameters.

References:

Choosing the right pattern

My practical rule: choose per surface, not per company.

Use Chat Components for trusted core workflows.
Use Component Systems for scalable, long-tail generation.
Use Embedded Generative UI only where ecosystem value clearly outweighs complexity.

Architecture notes that matter

Keep UI contracts owned by frontend.
Keep tool boundaries explicit (read, write, side effects).
Keep agent behavior portable across model providers.
Match security by pattern:
Chat Components: strict, typed contracts.
Component Systems: schema validation plus policy checks.
Embedded Generative UI: sandboxing, origin boundaries, and explicit permissions.

Implementation progression I recommend

Start with Chat Components for one critical workflow.
Add Component Systems for breadth and speed.
Add Embedded Generative UI selectively for ecosystem scenarios.

Keep one reference workflow (for example, flight booking) across all three stages.
It makes tradeoffs concrete and easier to explain to stakeholders.

Conclusion

Generative UI is not just a model capability.
It is a design and systems decision.

In 2026, the strongest strategy is intentional composition:

Start constrained.
Expand with structure.
Embed only where leverage is clear.

OpenClaw Setup, Configuration, and Key Takeaways

Brian Love — Wed, 18 Mar 2026 23:02:35 +0000

I set up OpenClaw on macOS with Telegram as my primary channel. The initial setup was quick, but I hit pairing and health-check failures that caused the first message to hang. This post captures what worked, what broke, and the operating policy I now use by default.

Environment

macOS desktop app + CLI
Node v22.14.0
OpenClaw 2026.2.19-2
Telegram bot channel enabled

1. Baseline setup

I started with the gateway and channel checks:

openclaw gateway probe
openclaw status --deep

That verified:

Gateway reachable on ws://127.0.0.1:18789
Telegram configured and healthy
Agent session available

2. Pairing the macOS app

My first blocker was:

gateway closed (1008): pairing required

I inspected pending and paired devices and approved the app request:

openclaw devices list --json
openclaw devices approve <request-id> --json

This ensured the macOS app had the expected auth state and roles.

3. Debugging "health check failed" and hanging sends

After pairing, the app still showed a failed health check and initial sends hung. The logs showed repeated health RPC failures tied to role auth behavior, which degraded responsiveness under load.

What helped most:

Comparing app behavior with app process stopped vs running
Watching gateway logs during connection attempts
Validating roles/tokens in device state before changing anything else

Key lesson: trust the logs over UI symptoms.

4. Stabilizing and re-validating

After correcting pairing/auth behavior, I re-ran validation:

openclaw gateway restart
openclaw gateway probe
openclaw status --deep

Final checks I care about:

Gateway RPC succeeds consistently
Telegram status is OK
No recurring pairing-upgrade loop
No repeating unauthorized health errors

Default security policy (what OpenClaw should always/never do)

This is the policy I now use as my default.

Always

Ask before risky actions; state what/why first.
Show exact files/commands changed.
Run relevant tests/lint before declaring done.
Redact secrets/tokens from output.
Ask clarifying questions when requirements are ambiguous.

Never (without explicit approval)

Destructive ops (rm -rf, git reset --hard, DB deletes, force-push).
Sending external messages (Telegram/email/webhooks) on my behalf.
Installing/updating system tools, packages, or services.
Accessing or exporting secrets/credentials.
Spending money or invoking paid APIs/services.

What I'm working on.

With openclaw I am working on threadplane - Agent UI for Angular

Key takeaways

Pairing roles must match real app behavior, not just initial connect success.
openclaw devices list --json is the fastest way to spot role mismatches.
Health checks are a real signal; if they fail, message send paths can stall.
Re-verify after every change with gateway probe and status --deep.
Strong boundaries reduce accidental risk while still keeping automation useful.

Building Web Applications We Can Trust - The Imperative of SRE

Brian Love — Sun, 11 Jun 2023 03:00:14 +0000

Building Web Applications We Can Trust - The Imperative of SRE

In this article, we explore the critical role of Site Reliability Engineering (SRE) for different types of SaaS owners and web developers, ranging from those overlooking reliability issues, those fighting to escape 'reliability hell', and those aware of the importance but lacking the resources to implement it.
We emphasize the necessity of SRE not just as a problem-solving method but as a culture, fostering a more reliable, trustworthy digital future.
We also introduce Polaris, an AI-powered tool designed to support and simplify the journey towards improved reliability.

In today's digital era, web application and Software-as-a-Service (SaaS) platforms dominate our interactions, dictating how we work, communicate, shop, and more.
As a result, reliability and trust have emerged as the most crucial features of these platforms.
In the throes of digital transformation, if there is one thing that every SaaS owner or web developer must focus on, it's Site Reliability Engineering (SRE).
Why? Let's explore.

Unresolved Reliability: Time Bomb or Opportunity?

The first group of SaaS owners and software engineers are those who are aware of reliability issues but opt to overlook them.
Their reasons may vary, from cost implications to rapid growth that seems to dwarf the need for reliability.
This can be a deceptive comfort zone, the mirage of a thriving business masking an impending reliability catastrophe.
Yes, you might have strong consumer lock-in, and your business might be on a steep growth curve.
However, remember this: trust, once lost, is hard to regain.

Consider what's at stake: your reputation, customer loyalty, and ultimately, your bottom line.
The need for reliability isn't a business choice —- it's a business imperative.
Don't wait for the time bomb to detonate; use the ticking to turn it into an opportunity.
By implementing SRE best practices now, you can preemptively address potential reliability issues and strengthen user trust, providing you with a competitive edge in the market.

The Long Journey Out of Reliability Hell: A Crucible for Change

The second group comprises SaaS owners and engineers painfully aware that they are in what we call "reliability hell".
You may be experiencing high churn rates, customer complaints, and even plummeting profits.
Getting out of reliability hell is indeed a Herculean task.
It takes time, effort, and significant investment in SRE best practices, tools, and processes.
Yet, it's a task worth undertaking, a crucible that can forge a more resilient and trusted business.

By embracing SRE, you are not just rectifying issues, but more importantly, you're establishing a culture of reliability within your organization.
This culture is a game-changer.
It ensures that reliability is built into the DNA of your applications, not bolted on as an afterthought.
It fosters an environment where every code, every deployment, every update is geared towards enhancing reliability.

Acknowledging the Need for SRE: A Call to Arms

Lastly, there are those SaaS owners and developers who are acutely aware of the need for reliability but find themselves unprepared to take it on.
The challenges of knowledge, skills, and resources can indeed be daunting.
But remember this: admitting the problem is the first step to the solution.

Fortunately, you're not alone in this journey.
Tools like Polaris, an AI-powered site reliability tool, can be invaluable.
Polaris is designed to detect outages and incidents in your web application in real time, helping you to navigate the complexities of SRE, even with limited resources.

Our vision for Polaris is simple: to help you build applications that people trust.
Because in a world reliant on digital, trust and reliability are the true currencies of success.

If you're ready to steer your web application or SaaS business towards a more reliable, more trusted future, we invite you to explore Polaris.
Polaris is currently in beta and we'd love for you to be part of our journey.
Feel free to sign up for Polaris, or contact us to learn more.

Together, we can build a world of reliable and trusted web applications.

Embracing Site Reliability Engineering

Brian Love — Wed, 10 May 2023 03:38:41 +0000

Site Reliability Engineering (SRE) is transforming the way software teams approach reliability and performance in modern web applications.
With an increasing number of frontend-focused engineers, it's essential to understand the fundamentals of SRE and implement a culture of reliability within your team and organization.
This blog post will introduce you to the basics of Site Reliability Engineering, its importance for software engineers and managers, and provide some best practices to kickstart your journey towards a more reliable web application.

What is Site Reliability Engineering?

Site Reliability Engineering is a discipline that combines aspects of software engineering and operations to build and maintain scalable and reliable systems.
Pioneered by Google, SRE focuses on automating infrastructure management, ensuring service reliability, and optimizing performance.
SRE emphasizes the use of Service Level Objectives (SLOs) and Error Budgets as a means to balance feature development, system stability, and user experience.

Why Should Software Engineers and Managers Be Concerned with Reliability?

Reliability is crucial for the success of any web application.
A reliable application ensures a positive user experience, leading to higher user retention, satisfaction, and ultimately, revenue.
As a software engineer or manager, it's your responsibility to ensure that your application is stable, performant, and consistently meeting the needs of your users.
Embracing SRE principles can help you identify and address performance bottlenecks and system failures, reducing downtime and improving overall system resilience.

Best Practices for Building a Culture of Reliability

First, define clear Service Level Indicators (SLIs) and Service Level Objectives (SLOs). SLIs are metrics that quantify your system's performance, while SLOs are target values for those metrics.
Establishing clear SLIs and SLOs helps your team set realistic goals for system reliability and provides a measurable way to track progress.
Ensure that these metrics are aligned with your users' expectations to maintain a high-quality user experience.

Second, implement monitoring and observability.
Monitoring and observability are crucial for understanding your system's health and performance.
Invest in tools that provide real-time insights into your application's performance and enable you to identify potential issues quickly.
Polaris, an AI-powered site reliability platform, is an excellent example of a solution that helps you effectively monitor and gain observability into your web applications' performance and reliability.

Third, automate incident response and management.
Automate processes for detecting, triaging, and resolving incidents to minimize the impact on your users.
Integrating your monitoring tools with incident management solutions, such as PagerDuty or Jira, can help streamline the process and reduce time to resolution.

Fourth, embrace a blameless culture.
Encourage a culture of learning and continuous improvement by treating failures as opportunities to learn rather than assigning blame.
Conduct blameless postmortems to identify the root causes of incidents and implement preventive measures to avoid recurrence.

Fifth, continuously iterate and improve.
Continuously evaluate and refine your processes, tools, and infrastructure.
Keep your team informed about best practices, and encourage open communication and collaboration to foster a culture of learning and improvement.

Conclusion

Site Reliability Engineering is a powerful approach to ensuring the reliability and performance of your web applications.
By understanding its fundamentals and adopting SRE best practices, you can build a culture of reliability within your team and organization, ultimately leading to more satisfied users and a successful web application.
Start your journey towards a more reliable web application today by embracing the principles of Site Reliability Engineering and leveraging the power of tools like Polaris to gain observability and insights into your system's performance.

Polaris

Building a culture of site reliability is critical to the success of an organization, especially if you are a SaaS product. But, it can be hard to climb out of reliability hell.

My team is building an AI-powered Site Reliability Platform that helps SaaS companies build apps people trust by increasing the reliability and performance of your web apps. We're currently in a closed-beta. However, don't fret, you can sign up for our beta and help us build a platform that changes the way we think about site reliability.

Typed Forms in Angular

Brian Love — Thu, 20 Oct 2022 18:47:47 +0000

Angular version 14 is a feature-packed release that brings new APIs, functionality, and a developer experience.
This includes one of the most requested feature improvements in Angular: typed forms.

In this article, you'll learn:

How to migrate to the new strongly-typed forms API in Angular version 14
Typed a FormControl
Typed a FormGroup
Typed a FormArray
New FormRecord
Mixing typed and untyped controls
Non-nullable controls

Let's dive in!

Typed Forms API FTW 🎉

If you have been using Angular's forms API, whether template-based or reactive forms, you likely have noticed that prior to Angular 14 much of the API surface had a lot of any types.

Angular (version 2, not AngularJS) was released in September of 2016 (after Flash died but before build tools took the world by storm). Not long after the release, developers started to note that the API was both not type-safe (or null-safe).
In fact, the most upvoted and commented on issue in the GitHub repository was created December of 2016 to report this problem.

Angular 14 introduces reactive form APIs that are both type-safe and null-safe. This is a big win for using reactive forms in Angular.
Unfortunately, the template-driven forms API is currently not strongly typed.

Migrating to Angular 14

To get started, you need to update your project to use Angular 14 to take advantage of the new APIs.

ng update @angular/cli @angular/core

Once your project is updated, you'll not that instance of FormControl and FormGroup have been migrated to the untyped classes:

FormControl is migrated to UntypedFormControl
FormGroup is migrated to UntypedFormGroup

Typed `FormControl`

In Angular 14, the FormControl class now has a TypeScript generic type of TValue whose default type assignment is any. What does this mean?

Prior to Angular 14, when accessing properties such as value the type was any, and when using the method setValue, it would accept any argument value.

Here are just a few of the class members that have been updated to use the TValue generic type:

setValue(value: TValue)
patchValue(value: TValue)
reset(formState: TValue)
getRawValue(): TValue
value: TValue

This is a big win for preventing runtime exceptions and regressions due to type errors!

It's important to note that the TValue generic type is inferred by TypeScript when newing-up a new FormControl instance, so it's not necessary to specify the generic type.
Let's look at an example.

const control = new FormControl('Mike');

Note, we did not specify the TValue generic type above.
Rather, the type is inferred by the value argument specified to constructor function when creating a new instance of the FormControl class.

Typed `FormGroup`

The purpose of Angular's FormGroup is to group form controls logically in order to track their state (value, validity, etc.) together.
Angular 14 also introduces updated typings for the FormGroup API.

Let's look at an example.

interface SignUpForm {
  name: string;
  email: string;
  subscribe?: string;
}

const signUpFormGroup = new FormGroup<SignUpForm>({
  name: new FormControl(''),
  email: new FormControl('')
});

Let's quickly review the code above:

First, we define a new SignUpForm interface.
The interface is only necessary if we have optional form controls. In this example, the subscribe control can be dynamically added and removed from the group.
Next, we create a new FormGroup instance, and since we have an optional control, we specify the generic type to the SignUpForm interface.
The name control's value is typed: string | null
The email control's value is typed: string | null
The subscribe control value is typed: string | null | undefined
The signUpFormGroup value is typed: Partial<{ name: string | null; email: string | null; subscribe: string | null | undefined }>

You may have noticed that the control values can be null or, if optional, undefined.
This is because Angular's form APIs allow for null values.
For example, if we invoke the reset() method on a control, the value is not set to the original/seed value, rather, it is set to null.
We'll show how to override this behavior below.

It should also be noted that the TValue for each control is also inferred as we previously learned.

Typed `FormArray`

Currently, TypeScript arrays are homogeneous.
This means that TypeScript expects that every item in an array is of the same type (including any).
For the sake of clarity, this is not to be confused with tuples which can have unambiguous types.

With that said, typed FormArray instances require that all controls are homogeneously typed.
If a FormArray requires heterogeneous types then the use of the UntypedFormArray is recommended.

In this example we'll create a new FormArray with an initial control.

lineItems = new FormArray([
  new FormControl('')
]);

Because we have defined the FormArray to include a control whose TValue is a string, the type of the array is inferred as: FormArray<AbstractControl<string, string>>.
The compiler now expects that each item in the array is a control whose TValue is a string.

If we attempt to add a new control to the array whose TValue is not a string, the compiler will throw an exception indicating:

lineItems.push(new FormControl(0));

The compiler exception indicates that there is an error.

Argument of type 'FormControl<number>' is not assignable to parameter of type 'AbstractControl<string, string>'.
Types of property 'value' are incompatible.
Type 'number' is not assignable to type 'string'.

This is a good thing! 😌

Ok, but what if our array of controls is initially empty?
In that case, we can specify the generic type of the controls:

lineItems = new FormArray<AbstractControl<string>>([]);

In the example above, we use the AbstractControl type and specify the TValue to be of type string as we expect every control's value to be a string.

New `FormRecord`

As we learned previously the FormGroup in Angular 14+ supports specifying a group of controls whose TValue types are known when creating the group, even when creating optional controls within the group.
However, what about a group of controls whose TValue is not known when creating the group.
To meet this use case, Angular 14 ships with a new FormRecord class.

Let's look at an example.

formGroup = new FormRecord<AbstractControl<string>>({});

Now that we have created the group of controls using the FormRecord class, we can start to add (and/or remove) controls from the group.

formGroup.addControl('street', new FormControl(''));

This code works as expected.
A new control is added to the group that meets the type definition.
However, what happens if we attempt to add a new control whose TValue is a number?

this.formGroup.addControl('no', new FormControl(0));

Again, the compiler throws an exception indicating that we cannot add this control to the group due to the type constraints.

Argument of type 'FormControl<number>' is not assignable to parameter of type 'AbstractControl<string, string>'.
Types of property 'value' are incompatible.
Type 'number' is not assignable to type 'string'.

The UntypedFormGroup class supports the user requirements in the event that we need a group of controls whose values are heterogeneous.

Mixed Types

We can declare mixed types of controls when working with a group of controls of heterogeneous types as long as we declare the controls when creating the group.
Further, we can use the UntypedFormControl class to declare a control whose TValue type is any (under the hood, this is a type whose generic type is preset to any).

Let's look at an example.

export class AppComponent implements OnInit  {
  formGroup = new FormGroup({
    street: new FormControl(''),
    no: new FormControl(0),
    postalCode: new UntypedFormControl()
  });

  ngOnInit(): void {
    const street = this.formGroup.value.street;
    const no = this.formGroup.get('no').value;
    this.formGroup.get('postalCode').setValue(12345);
    this.formGroup.get('postalCode').setValue('ABC123');
  }
}

This all works as we expect.
We have a few controls, each with their own TValue, including the untyped control whose TValue is any.

Non-nullable Controls

If you recall from earlier, we mentioned that resetting a form control state will set the value to null, not the initial/seed value as we might expect.
With non-nullable form controls, we can explicitly instruct the compiler that the value is reset to the initial value when invoking the reset() method.

Let's look at an example

export class AppComponent implements OnInit {
  formGroup = new FormGroup({
    street: new FormControl('', { nonNullable: true })
  });

  ngOnInit(): void {
    this.formGroup.get('street').reset();
    const street = this.formGroup.value.street;
    console.log(street); // empty string, NOT null
  }
}

Key Takeaways

There are a few key takeaways when using Angular 14's updated forms API:

The FormControl, FormGroup, and FormArray signatures have been updated to support TypeScript generics.
The TValue type is inferred where possible.
FormGroup supports enumerated, homogeneous, and optional controls.
FormRecord supports non-enumerated (dynamic) and homogenous controls.
UntypedFormControl is a non strongly-typed FormControl. Or, in other words, the TValue type is preset to any.
UntypedFormGroup is a non strongly-typed FormGroup.
FormArray supports homogeneously typed controls.
UntypedFormArray is a non strongly-typed FormArray.
The nonNullable supports resetting a control state to the initial/seed value.
Through strict types and template type checking, we can avoid runtime exceptions and reduce regressions.

Need Help?

Do you have questions? We can help! LiveLoveApp provides angular consulting. We can answer your questions, perform an architecture review of your application and help you to implement best practices to improve your software development performance.