The New AI Full Stack Map

Why this chapter matters

The "new full stack" conversation is directionally right, but it becomes dangerous when every term is treated as one layer of the same ladder. Generative UI, agent orchestration, RAG, MCP, A2A, inference, and vector databases solve different problems. A frontend architect needs to separate them clearly before choosing tools.

Old full-stack work was often described as UI, API, database, and infrastructure. That model still exists. The difference is that AI products add probabilistic behavior, streaming work, long-running tasks, retrieval, tool access, human approval, generated interface state, and evaluation loops. The complexity did not replace CRUD; it sits on top of it.

Core mental model

An AI product is not a chatbot bolted onto a page. It is a system where user intent moves through several boundaries:

Layer	Old responsibility	AI-era responsibility
UI	Render known states	Render known states plus model-proposed states
Client protocol	Request and response	Streaming events, tool progress, cancellation, generated UI, approval
API	Validate commands and return data	Route intent into inference, tools, retrieval, and workflow state
Agent/workflow	Usually absent	Plan, call tools, branch, retry, ask for human input
Context/data	Database reads	RAG, semantic search, memory, permissions, citations
Infrastructure	Host services	Host inference gateways, model routing, evals, traces, prompt/version control
Governance	Code review and tests	Evals, red-team cases, policy gates, cost controls, model drift monitoring

The practical architecture question is not "Should we learn agents?" It is "Where do we allow nondeterminism, and what deterministic contracts surround it?"

Source-derived architecture notes

Firecrawl research across AG-UI, A2UI, MCP, A2A, LangGraph, CrewAI, Strands, Pinecone, and Weaviate shows a repeating pattern: the AI stack is becoming protocolized. AG-UI frames the agent-to-user connection as event-based. A2UI frames generated interface output as declarative and renderable by trusted clients. MCP standardizes access to tools, data, and workflows. A2A standardizes agent-to-agent coordination. Agent frameworks provide orchestration primitives. Vector/RAG systems provide retrieval context.

For a frontend architect, the key insight is that "AI UI" is now a distributed system problem:

• The model may propose text, actions, state changes, or UI structures.
• The frontend must validate and render only allowed component shapes.
• The backend must preserve conversation, workflow, authorization, and audit state.
• Retrieval must respect permissions and provide inspectable grounding.
• Long-running work must expose progress, cancellation, and recovery.
• Quality must be measured through evals and field behavior, not demos alone.

Layer-by-layer decision model

Decision	Conservative starting point	Advanced pattern	Use the advanced pattern when
User experience	Deterministic forms plus AI assistance	Generative UI that adapts layout and controls	Tasks vary widely and static screens cause high friction
Agent runtime	Single request with tool calls	Stateful workflow graph or crew	Work is multi-step, resumable, approval-driven, or cross-tool
UI protocol	App-specific streaming endpoint	AG-UI-compatible event contract	Multiple agent backends or clients need shared behavior
Generated UI	Fixed components chosen by server	A2UI-style declarative UI schema	The agent needs to compose approved UI from intent
Retrieval	Keyword/database lookup	RAG with vector and hybrid search	Useful answers require unstructured or semantic knowledge
Tool access	Backend-owned integrations	MCP servers with capability boundaries	Many tools need reusable, discoverable, permissioned access
Agent federation	One application agent	A2A-style agent coordination	Separate agents owned by different teams/systems must cooperate

Architecture principles

1. Keep the deterministic shell

The app shell, auth, routing, component registry, accessibility semantics, design system, permissions, and audit rules should remain deterministic. Let AI propose within those boundaries. Do not let the model own raw HTML, arbitrary JavaScript, authorization checks, or irreversible actions.

2. Treat generated UI as data, not code

Generated UI should be a typed payload that references approved components and allowed props. The rendering client maps the payload into real components. This protects accessibility, security, visual consistency, localization, analytics, and testability.

3. Design for streaming from day one

AI work often takes time. Users need to know what is happening before the final answer exists. The frontend should render partial answer text, retrieval status, tool progress, approval prompts, generated UI updates, and failure recovery as separate event types.

4. Preserve user intent

When an AI task fails halfway through, the user should not lose their goal. Persist the input, selected context, workflow id, pending action, generated draft, and last safe checkpoint. This is the same senior mindset used for offline-first and payment flows, applied to inference-heavy products.

5. Measure usefulness, not output volume

Long answers, clever widgets, and many tool calls are not success metrics. Track task completion, correction rate, approval rejection rate, grounded-answer rate, time-to-first-useful-state, cost per completed task, and user trust signals.

Failure modes

• Protocol soup: every layer uses a different event shape, so debugging requires reading frontend code, backend logs, agent traces, and model prompts manually.
• Generated UI injection: the model emits untrusted markup or props that bypass design-system and security controls.
• Agent theater: the product uses multi-agent orchestration for tasks that need a simple deterministic workflow.
• RAG without ownership: documents are embedded without freshness, permission, or citation strategy.
• No cancellation: long-running inference keeps spending money after the user navigates away.
• Demo-only quality: success is measured by happy-path examples rather than adversarial and regression evals.

Learning path for frontend architects

1. Learn the AI stack map: what belongs to UI, workflow, context, tools, and infrastructure.
2. Learn generative UI architecture: component registries, schemas, streaming, validation, accessibility, and fallback.
3. Learn AG-UI and A2UI: protocol vs UI specification, and how they can work together.
4. Learn one agent framework deeply: LangGraph, CrewAI, Strands, or your organization's chosen runtime.
5. Learn RAG fundamentals: chunking, embeddings, vector search, hybrid search, metadata filters, access control, and citations.
6. Learn integration protocols: MCP for tools/context, A2A for agent-to-agent coordination.
7. Learn production controls: evals, observability, cost budgets, prompt/version management, security review, and incident response.

Reference architecture: AI-assisted product workflow

A realistic AI full-stack feature usually looks like this:

User intent
  -> app shell captures task, user role, selected objects, device context
  -> AI interaction endpoint creates workflow id and policy context
  -> retriever gathers permitted sources and source ids
  -> agent workflow plans bounded steps and calls approved tools
  -> protocol stream sends progress, tool events, UI proposals, and approvals
  -> frontend validates generated UI against registry
  -> user edits, rejects, approves, or asks for regeneration
  -> backend commits approved side effects through normal product APIs
  -> telemetry/evals record outcome, cost, latency, corrections, and failures

Each arrow is an architectural boundary. The senior mistake is to collapse them into one endpoint called /ai. That makes early demos fast, but it makes production debugging almost impossible. When the output is wrong, the team cannot tell whether the failure came from intent capture, retrieval, prompt design, workflow planning, tool access, UI schema validation, frontend rendering, or user approval logic.

Capability maturity model

Use this maturity model to sequence learning and implementation.

Level	Capability	What the frontend owns	Exit criteria
0	Text assistant	Chat shell, markdown rendering, basic loading/error	Safe for low-risk Q&A, no side effects
1	Tool-result UI	Tool cards, result renderers, source display	Known tool outputs render as reliable components
2	Static GenUI	Agent selects predefined components	Registry, schemas, fallback states, telemetry exist
3	Declarative GenUI	Agent emits constrained component trees	Versioned UI schema, migration, replay, validation exist
4	Stateful workflow UI	Long-running tasks with approval and resume	Durable workflow state, cancellation, progress, audit exist
5	Multi-agent/app ecosystem	Agents/tools/apps coordinate across boundaries	Policy gateway, A2A/MCP governance, incident playbooks exist

Most teams should not jump from level 0 to level 5. The hard part is not producing a cool interface. The hard part is maintaining user trust when the system has variable inputs, changing data, partial failures, cost limits, and real permissions.

Team ownership model

AI full-stack architecture cuts across frontend, backend, data, security, design, and product. Make ownership explicit.

Concern	Primary owner	Frontend architect responsibility
Component registry	Frontend/design system	Define allowed components, props, accessibility, fallback, analytics
Interaction protocol	Frontend plus platform/backend	Define event lifecycle, ids, streaming, cancellation, resume
Agent workflow	AI/backend platform	Ensure workflow state maps to visible user states
Retrieval/RAG	Data/AI platform	Require source ids, permission metadata, citation quality
Tool access	Backend/platform/security	Require approval UI, side-effect classes, audit events
Prompt/model versions	AI/platform	Surface version in traces and rollback plans
Evals	Product/AI/platform	Include UX, accessibility, and generated UI schema evals
Incident response	Engineering leadership	Ensure kill switches can disable model, retriever, tool, or component

If no team owns a boundary, the frontend eventually becomes the accidental integration layer for everything.

Architecture review questions

Use these questions before approving a new AI full-stack feature:

Question	Good answer
What job is AI doing that deterministic UI cannot do well?	The team names specific task variability or cognitive load
What remains deterministic?	Auth, permissions, design-system behavior, side effects, audit, fallback
What can the model propose?	Text, component type, component props, tool arguments, next-step suggestions
What can the model never do directly?	Execute arbitrary code, bypass auth, commit risky action, hide evidence
How is user intent preserved?	Workflow id, input snapshot, generated draft, edit state, resume
How do we know it works?	Baseline comparison, eval suite, RUM, correction/reject metrics
How do we turn it off?	Feature flag per model, retriever, tool, component, tenant, role

Scenario: AI renewal workspace

Imagine a B2B SaaS product where a customer success manager asks, "Prepare a renewal plan for Acme."

A shallow implementation returns a long text summary. A real AI full-stack implementation does more:

1. Captures selected customer, user role, region, and account permissions.
2. Retrieves permitted CRM notes, usage trends, support tickets, contract terms, and previous renewal emails.
3. Runs a workflow that identifies risk, drafts talking points, proposes discount boundaries, and requests approval for external communication.
4. Streams progress: "Checking usage," "Reading support tickets," "Drafting plan," "Waiting for approval."
5. Generates a workspace containing a risk summary, cited evidence, editable email draft, task checklist, and approval panel.
6. Lets the user edit the draft and reject incorrect claims without restarting.
7. Sends approved actions through normal CRM/email APIs with audit logs.
8. Records outcome: time saved, rejected claims, sources used, email sent, cost, latency, and follow-up conversion.

This example shows why GenUI is not a frontend-only topic. The UI can only be good if retrieval, workflow, tools, permissions, and telemetry are designed together.

Verification checklist

• The architecture diagram separates UI protocol, generated UI schema, agent workflow, retrieval, tools, and inference.
• The model cannot emit arbitrary executable UI.
• Long-running tasks have progress, cancellation, resume, and failure states.
• Retrieval enforces document permissions and exposes citations or provenance.
• Tool calls have authorization, audit logs, idempotency, and human approval for risky actions.
• Quality is covered by eval suites, regression examples, and production telemetry.

Exercises

1. Take a current CRUD feature and redesign only one step as AI-assisted. Identify what remains deterministic.
2. Draw the event lifecycle for a user asking an agent to complete a multi-step task.
3. Write an ADR deciding whether your product needs chat, generative UI, a deterministic wizard, or a hybrid.
4. Define five eval cases that would catch regressions in a GenUI workflow.

Source lens

This chapter is synthesized from Firecrawl research on the official AG-UI docs, A2UI site and Google repository, Model Context Protocol docs, A2A project repository, LangGraph material, CrewAI docs, Strands Agents material, Pinecone RAG guidance, and Weaviate generative search/RAG guidance.