Why Agent Frameworks Have Too Many Nouns
Three primitives for the open-ended layer. Deterministic process control belongs one layer above them.
Many agent frameworks ask teams to learn an expanding vocabulary before they can build anything useful.
That is not always bad. Rich abstractions can be powerful. But in enterprise projects, every extra concept has a cost:
more onboarding
more places to make mistakes
more framework-shaped design decisions
more friction between experimentation and production
That is why I think simpler runtime architecture wins more often than more ornate framework taxonomy.
Three Runtime Primitives
For the open-ended agent runtime, we organize the system around three primitives:
Interactions
Skills
Tools
That is not the whole product. Processes sit one layer above them for deterministic business workflows. But inside the agent runtime itself, these three primitives carry most of the weight.
Interactions
The core abstraction is the Interaction.
An Interaction carries prompts, model configuration, tool access, and optional result schema. What changes its behavior are flags:
is_agent— execute it as a durable, multi-turn agent runis_tool— make it callable by other agents as a sub-agentis_skill— use it as instructional capability that can unlock tools
Those modes are composable.
The same capability can behave differently depending on context:
as an agent when a user launches it directly,
as a tool when another agent delegates to it,
as a skill when another agent only needs its guidance and unlocked capabilities.
That avoids a common kind of duplication: rebuilding the same domain capability three times because the framework wants separate concepts for agent, tool, and knowledge module.
Two execution paths
Not everything needs the full workflow harness.
Sometimes you want a single structured LLM call:
POST /api/v1/execute
{ "interaction": "classify_document", "data": { "text": "..." } }
Sometimes you want a durable interactive run with tools, streaming, checkpoints, and signals:
POST /api/v1/agents
{ "interaction": "contract_analyst", "data": { "task": "Analyze Q3 renewals" }, "interactive": true }
Same Interaction definition. Different execution path.
That matters because a fast synchronous classification call and a four-hour agent run are not the same kind of workload, even if they share prompts and schemas.
Skills
Skills solve two different problems at once.
1. Progressive disclosure
Large tool menus reduce selection quality. That is not theory. It shows up in real systems.
So instead of exposing everything at once, the runtime can hide capabilities behind learn_* skills. An agent calls something like learn_web_search, gets the instructions for using that capability well, and unlocks the tools associated with it.
Knowledge and capability arrive together.
This pattern has matured enough that it is no longer a quirky design choice. It is becoming a standard way to keep agent tool use disciplined.
2. Business knowledge
A skill is not just a tool bundle.
It is also a place to encode how work should be done:
renewal policies
compliance playbooks
contract review heuristics
data quality rules
report-writing conventions
That knowledge can be written in the language your team actually uses, and it can travel with the tools needed to apply it.
The concrete proof point for us now is the Studio Assistant. It is explicitly skill-first. It starts with a narrow default toolset, loads domain skills before it can mutate real project resources, and uses route context plus pre-fetched project inventory to stay anchored in the builder’s actual working context.
That is a much stronger demonstration than describing skills as an abstract concept.
Tools
The real power of an agent platform is not in having “many tools.” It is in whether the tool system behaves like infrastructure instead of a bag of wrappers.
That means:
consistent output formats
consistent error formats
context protection when outputs are large
artifacts as first-class outputs
interoperability between search, documents, files, and external tools
Without those properties, agent reliability degrades fast as you add capabilities.
Extension should not create fragmentation
We support custom tools through tool servers. They can be built in TypeScript, Python, Go, or anything else that can speak HTTP.
With the TypeScript SDK, the shape is straightforward:
import { createToolServer, ToolCollection } from "@vertesia/tools-sdk";
const tools = new ToolCollection({
name: "crm-tools",
tools: [{
name: "lookup_customer",
description: "Look up customer by ID or email",
params: { type: "object", properties: { id: { type: "string" } } },
execute: async (ctx) => ({ customer: await crm.find(ctx.input.id) })
}]
});
export default createToolServer({ tools: [tools] });
The important part is not that custom tools exist. Every serious framework supports custom tools.
The important part is that custom tools join the same runtime model:
same context protection,
same progressive disclosure,
same artifact behavior,
same observability expectations.
That keeps extensibility from degrading into fragmentation.
Open protocols: MCP and A2A, both directions
Custom tools are not the only way capabilities enter the system. Vertesia speaks the open protocols both directions, for the whole runtime model:
MCP servers as capability sources. Any MCP server’s tools become available inside Vertesia — agents can use them, processes can wire them as deterministic tool nodes, and they get the same scoping, observability, and context protection as native tools.
Interactions, agents, and tools exposed as MCP and A2A. Whatever you build in Vertesia — a tool, an interaction, an agent — is also published as an MCP tool and an A2A endpoint. Other systems and agents can consume it without bespoke integration.
That bidirectional posture is where composability compounds. The same Interaction can be an agent inside Vertesia, a tool another agent calls, an MCP capability a third-party app exposes to its own model, and an A2A endpoint another agent system invokes — all from one definition. Tool ecosystems are converging fast right now; a runtime that only speaks its own protocol becomes an island. One that speaks the open protocols in both directions becomes a substrate other systems build on.
Where Processes Fit
This is the piece the earlier series drafts did not make explicit enough.
Interactions, Skills, and Tools are the runtime building blocks for open-ended agent work.
But business processes are not just “bigger agents.”
For business workflows with typed state, transitions, human gates, and auditability, we now use the Process Engine above the runtime layer. The process owns deterministic control. Agent nodes handle bounded reasoning tasks inside it.
That means the series should be precise:
Interactions, Skills, and Tools are the runtime primitives for agents.
Processes are the control plane for hybrid business workflows.
Once you separate those layers, the architecture becomes easier to understand.
Tools are also process primitives
There is one piece worth making explicit, because it is not obvious from the runtime view alone.
Tools are not private implementation details of the agent runtime. The same tool a worker agent calls inside a bounded reasoning loop can also run directly as a deterministic process node — no model in the path. If a step is known, use a tool node. If a step requires judgment, use an agent node with access to the same tools. One capability surface, two ways to use it, governed under the same process contract.
That is what makes the layering honest: tools, skills, and interactions don’t get re-implemented at the process layer. The process engine reuses them and adds the contract — typed context, declared writes, explicit transitions, scoped tool access, MCP capabilities under the same governance. I wrote up that full design separately in The Engine Is the Contract: Rethinking Process Engines for the Agent Era — including how an optional AI supervisor can steer a run through validated commands without escaping the contract.
Why This Matters
The value of a smaller runtime model is not philosophical elegance. It is composability.
With a small runtime vocabulary, you can build:
a single-turn classifier
a long-running interactive agent
a specialist sub-agent callable as a tool
a skill-first assistant
a bounded worker inside a deterministic business process
a deterministic tool node in a process — same tool, no model in the path
without inventing a new abstraction for each case.
The complexity still exists. It just lives in the platform instead of leaking into your application code as a constantly growing taxonomy.
That is the bet.
Not “three things explain the whole platform.”
More precise than that:
“Three runtime primitives are enough for the open-ended agent layer, deterministic process control belongs one layer above them, and the same primitives travel between both layers under one contract.”
I’m writing this from what we’ve learned building Vertesia. If that three-layer split is useful, subscribe for the rest of the series.
Next in the series: CrewAI Gets You to the Demo. Then What? — where the prototype-to-production gap starts to open.