An ai-sdk has one job. It runs the model. It sends the request, handles tool calls, and loops until the task is done. Infrastructure has a different job: coordinating agents around that loop, passing messages, and keeping a record. Blur the two and multi-agent systems get hard to reason about.

Below, each job gets its own explanation. Then the article shows how they work together and where DNotifier fits.

The Two Jobs

Job One: Model Execution

Start with the SDK. Its job is talking to a model provider and making the replies useful. The AI SDK documentation describes agents as language models that use tools in a loop (AI SDK docs, Agents overview).

Inside that loop, the SDK handles a few things. Context comes first: the messages the model sees at each step. Then tools, which are ordinary functions with a description and an input schema. Last, stop conditions like a step limit.

All of it runs in your application process, for one agent. And often that’s plenty. A single loop is a perfectly good design.

Job Two: Coordination

Coordination starts where one loop ends. Say you’ve got three agents instead of one. Who decides which runs first? Who carries results between them? Who notices when one fails?

Those questions map to four responsibilities. Orchestration picks the next agent and the order. Messaging moves information between components and out to users. Application state holds workflow data and progress. Observability records what each step did.

An SDK loop doesn’t cover these across agents. That’s interpretation, not a documented limit. The SDK docs call agents flexible but non-deterministic, and suggest explicit control flow when you need repeatable results (AI SDK docs, Agents overview).

How Both Work

Inside One Agent

Follow one request. The SDK sends it to the model along with your tool list. The model answers with text or asks for a tool. If it wants a tool, the SDK runs your function and appends the result to the context. Then it’s back to the model.

The loop stops on a condition you set. Between steps you can even swap the model, tools, or messages (AI SDK docs, Loop Control). That’s light orchestration. But it stays inside one agent’s run.

Across Agents

Here a coordinator holds the plan. It calls one agent, reads what came back, and decides what’s next. Messages carry results forward and send status updates to users.

State keeps workflow data between steps, so the next agent sees the last one’s output. Traces log each step’s input, output, and status. When a run breaks, you find the bad step. No rereading one giant transcript.

Both Layers Together

Does a second model call make a second agent? No. One model can power many agents. It can also call itself ten times. A distinct agent has its own role, tools, and execution context, plus an outside coordinator.

Here’s a hypothetical refund workflow. A triage agent reads the ticket and classifies it. A policy agent searches the knowledge base, with no access to orders. A review agent checks the draft reply and can call the order API.

A coordinator runs them in order and passes results along. If review rejects the draft, it reruns the policy agent. Each agent runs its own SDK loop inside.

Notice the split. No SDK loop decides that review comes after policy. The coordinator does. Execution happens within agents. Coordination happens between them.

Where DNotifier Fits

DNotifier provides one SDK and one API with multi-model support. It supports the coordination job: orchestration, messaging, and observability. It doesn’t replace your model providers, your tool code, or every agent framework.

The DNotifier SDK documentation describes workflows with named agents and shared workflow state (DNotifier SDK docs, pub.dev). You create an agent with defineAgent, register it on a Workflow, and call ctx.runAgent from the entry function. That function plays coordinator.

In the hypothetical, triage calls ctx.sendAI. The policy agent uses ctx.search for semantic search over your knowledge base. Results move through ctx.state, a map shared across the run.

For messaging, your app can call send over the WebSocket transport to push status updates to the customer. Turn on observability: true and, per the documentation, SDK calls and recorded steps show up in the workflow dashboard.

Multi-model support means triage could run on a small model and review on a stronger one. But that choice alone doesn’t create agents. Roles and coordination do.

Some work stays yours. Prompts, tool code, and permissions live in your application, and model providers still run inference. The public documentation doesn’t describe durable checkpoints, replay, or automatic retries. Plan for those yourself.

The Trade-Off

Distinct agents aren’t free. Every handoff adds model calls, latency, and tokens. A three-agent flow can mean three model calls where one loop would make one or two. Every boundary is also one more thing to test and debug.

Shared state couples agents too. Change the policy agent’s output shape and the review agent breaks. Treat outputs like contracts, and test them.

A platform SDK adds a dependency as well. The DNotifier SDK is proprietary, according to its pub.dev listing. So start with one loop. Split into agents when tool permissions need isolation, context size hurts quality, or roles need independent testing.

FAQ

Does an AI SDK replace infrastructure?
No. An SDK runs model calls and tool loops. Coordination, messaging, state, and traces across agents need another layer. You build it or adopt it.

Is a self-calling model multi-agent?
No. A model calling itself has one role, one context, and no outside coordinator. Distinct agents separate those things.

When should I add separate agents?
When tools, context, or testing need separation. Before that, a single loop is simpler and cheaper to run.

The SDK runs the agent. Infrastructure runs the system around it. If coordination and traces are slowing your team down, DNotifier is worth a look.