Raltic field guide
AI agent stack layers: framework, builder, runtime, observability, and workflow room
Most agent-platform comparisons fail before the feature table begins. They place a developer SDK, a visual builder, a cloud runtime, a trace viewer, and a team workspace in one category even though each owns a different part of the work.
Move from the definition to the operating decision without losing the thread.
Direct answer
The AI agent stack has five practical layers: SDKs and frameworks define agent behavior; visual builders package flows and applications; runtimes execute and persist work; observability and evaluation tools explain and score behavior; and workflow rooms coordinate the people, evidence, tasks, and decisions around that work. One product may cover several layers, but no label proves that it covers the layer your team actually needs.
Separate how an agent is built from how its work becomes an accepted team outcome.
- 01
Build
Define models, tools, prompts, state, routes, and application behavior.
- 02
Run
Execute, persist, resume, scale, secure, and deploy the agent system.
- 03
Understand
Trace steps, evaluate quality, compare versions, and catch regressions.
- 04
Operate
Assign work, review evidence, correct outputs, and record the decision.
Why the agent-platform category keeps breaking
The category name describes a market, not a stable product boundary.
A team searching for an agent platform may be trying to build a customer-facing assistant, connect a model to ten business systems, run a durable graph, debug tool failures, or let product and engineering review agent work together. Those are separate purchasing jobs. A feature matrix that ignores the job rewards whichever vendor covers the most nouns.
Start with the object the team must own after purchase. Source code points to a framework decision. A published application points to a builder. A fleet of long-running processes points to runtime infrastructure. A set of traces and regression cases points to observability and evaluation. A recurring cross-functional decision points to an operating workspace.
- 01What must exist after the first month?
- 02Who builds and maintains it?
- 03Where does execution state live?
- 04How is failure diagnosed?
- 05Who accepts the outcome?
Layer 1 and 2: frameworks define behavior; builders package an application
Frameworks offer code primitives, while visual builders make an application graph and delivery surface easier to assemble.
OpenAI Agents SDK, Google ADK, Microsoft Agent Framework, LangGraph, and CrewAI give developers abstractions for agents, tools, handoffs, state, guardrails, workflows, or evaluation. The application team still decides how those pieces become a product. The framework is valuable precisely because it leaves that product open.
Dify, Flowise, Langflow, n8n, and Copilot Studio move more decisions into a canvas and managed environment. They may add knowledge, connectors, tests, logs, APIs, embedded interfaces, or publishing. This reduces setup, but the canvas also becomes a production artifact with versions, credentials, owners, and failure paths that need maintenance.
- 01Framework: code and runtime primitives
- 02Builder: graph, configuration, and app packaging
- 03Check whether the canvas is source-controlled
- 04Check how custom code and components are reviewed
- 05Test migration before the first large workflow
Layer 3: runtime and control plane keep work alive
The runtime owns execution; a control plane helps teams govern many executions and agent identities.
A serious runtime question appears when work must survive a process restart, wait hours for approval, resume from a checkpoint, isolate tools, scale across tenants, or preserve session state. Some frameworks supply persistence hooks, while cloud platforms provide managed sessions, memory, identity, gateways, policy, and deployment infrastructure.
Do not buy a control plane because the architecture diagram looks complete. A small team running one reviewed workflow may need a much narrower product. Conversely, a company operating hundreds of customer-facing agents should not expect a collaboration room to replace runtime isolation, policy enforcement, fleet management, or service-level monitoring.
- 01Durability and resume semantics
- 02Tenant and process isolation
- 03Identity and tool authorization
- 04Deployment, scaling, and rollback
- 05Fleet policy and operational ownership
Layer 4: observability explains behavior; evaluation judges it
Tracing and evaluation use the same run data for different questions.
A trace can show the model call, retrieved documents, tool arguments, handoff, latency, and error. It tells an engineer what happened. An evaluation adds a criterion: whether the tool was appropriate, the evidence was grounded, the route matched an expected trajectory, or the final output satisfied a rubric.
Production quality needs a loop between the two. Inspect a failure, label the failure mode, promote a representative case into a dataset, run the candidate version against the same case, and monitor after release. A dashboard with no regression process is an archive, not a quality system.
- 01Trace one complete unit of work
- 02Attach version and environment metadata
- 03Define expected behavior with reviewed cases
- 04Measure judge and human disagreement
- 05Feed production failures back into tests
Layer 5: the workflow room records what the team decided
Technical telemetry cannot explain every business decision made around a run.
A team may reject a technically valid answer because a source is stale, a customer constraint changed, or the proposed action conflicts with a product promise. That reasoning often lives in a meeting, private message, or review comment. A workflow room keeps the brief, posted evidence, agent updates, tasks, corrections, and final decision in a form that another person can read.
This layer complements the others. Engineers still need traces and automated regression tests. The operating team needs to know who asked for the work, what was considered sufficient, which concerns changed the result, and who owned acceptance. Raltic is built for that team-facing record and does not claim to replace the application framework beneath it.
- 01Original brief and decision owner
- 02Evidence visible to the reviewer
- 03Agent and human contributions in context
- 04Tasks and unresolved follow-up
- 05Accepted outcome and rationale
Primary sources
Product and practice claims in this guide are grounded in current first-party or standards sources. Raltic product claims are limited to shipped behavior described on this site.
FAQ