1 Overview: Agents as the Unit of Design

Tutorials 17 through 19 built agents inside two frameworks — Semantic Kernel and AutoGen — as a mechanism: a kernel plus instructions and a thread, or a conversable agent exchanging messages. This tutorial steps back from mechanism to architecture. Agent-first architecture asks a different question: if an application's primary unit of functionality is an agent with a goal, rather than a fixed request/response endpoint, how does that reshape how you design the whole system — its structure, how components talk to each other, how you keep it safe, and how you get there from what you already have?

This advanced tutorial covers designing agent-first architectures as a discipline (not a framework feature); agent communication models — how agents actually exchange information at a system level; governance and safety for agents — the organizational and technical controls that make autonomy acceptable in production; and converting a traditional AI pipeline into an agent-based system, a concrete migration you can apply to real code. Every idea here sits above the frameworks from tutorials 17–19 — it applies whether the agents underneath are Semantic Kernel, AutoGen, or something else entirely.

2 Learning Objectives

• Explain what agent-first architecture means as a design discipline and contrast it with request/response architecture.
• Describe agent communication models — direct messaging, message bus, blackboard — and choose the right one for a system.
• Design governance and safety controls for agentic systems: policy engines, sandboxing, audit trails, kill switches, and capability scoping.
• Plan and execute converting a traditional AI pipeline into an agent-based system incrementally, without a risky full rewrite.
• Judge when agent-first architecture is the right choice for a system and when a simpler design serves better.

3 Prerequisites

• Tutorials 17–19: agents, planners, orchestration patterns (Semantic Kernel) and conversable agents, collaboration patterns, roles (AutoGen) — this tutorial assumes you can build an agent, not just read about one.
• Tutorial 12's function-calling safety discipline and tutorial 13's resilience/observability patterns, which remain the foundation under any architecture.
• General software architecture literacy: services, message queues, and the tradeoffs between coupling and flexibility.
• A traditional AI pipeline of your own (even a simple retrieve-then-prompt RAG flow from tutorial 15) is ideal for the conversion walkthrough.

4 Key Concepts: From Fixed Paths to Goal-Driven Units

A request/response architecture organizes a system around fixed code paths: a request comes in, a predetermined sequence of steps runs, a response goes out — the same shape every time for a given endpoint. An agent-first architecture organizes a system around agents as the unit of functionality: each agent owns a goal and a set of tools, and decides its own next action rather than following one hardcoded sequence. The shift is from 'what steps always run' to 'what can this component decide to do toward its goal.'

The other three subtopics follow directly from this shift. If agents are the unit of design, they need a communication model for how they find and talk to each other (agent communication models). Because they decide their own actions, they need governance and safety controls proportional to that autonomy. And because most real systems already have working pipelines, converting a traditional AI pipeline into an agent-based system is a practical migration problem, not a green-field exercise.

5 Deep Dive 1: Designing Agent-First Architectures

Designing agent-first means deciding, deliberately, which parts of a system should be agents and which should stay as ordinary services. An agent earns its place when a task's steps genuinely depend on runtime judgment — which tool to use, whether to ask a follow-up question, how to recover from an unexpected result — not when a task is simply 'complex but fully specifiable in advance.' A complex-but-fixed workflow (validate, transform, save, notify) is still better as a pipeline; an open-ended one (diagnose this incident and propose a fix) is a better fit for an agent.

A practical design checklist: identify the goal each agent owns (narrow and specific, as tutorial 18/19 stressed); decide its tool/plugin surface (least privilege — capability scoping, deep-dive 3); decide whether it needs cross-turn memory (a thread) or is stateless per invocation; and decide how it is discovered and invoked by the rest of the system — which is exactly the agent communication model question in deep-dive 2. An agent registry — a directory of available agents, their responsibilities, and how to reach them — plays the role a routing table plays in request/response systems, and becomes essential once a system has more than a couple of agents.

6 Deep Dive 2: Agent Communication Models

Once a system has multiple agents, they need a way to exchange information — a request for help, a result, a status update. Three communication models cover most designs. Direct messaging has one agent call another directly, by name or reference — simple and traceable, but it couples the caller to knowing exactly who to call, which gets brittle as agents are added or replaced. A message bus routes messages between agents without either side knowing the other directly — the sender publishes, interested agents subscribe — trading some directness for loose coupling and easier extension. A blackboard pattern has agents read and write shared state that any participant can observe, useful when many agents contribute partial information toward a shared understanding rather than passing discrete requests.

// Direct messaging: the caller must know exactly which agent to invoke.
var billingResult = await billingAgent.InvokeAsync("Check invoice INV-2031", thread);

// Message bus: the caller publishes an event; it doesn't know who (if anyone) handles it.
await messageBus.PublishAsync(new AgentTaskRequested(
    TaskType: "CheckInvoice",
    Payload: "INV-2031"));

// Any agent subscribed to "CheckInvoice" tasks picks it up independently —
// a new specialized agent can start handling this task type with zero changes
// to the code that published the request.
messageBus.Subscribe<AgentTaskRequested>(async request =>
{
    if (request.TaskType == "CheckInvoice")
        await billingAgent.InvokeAsync($"Check invoice {request.Payload}", thread);
});

7 Deep Dive 3: Governance and Safety for Agents

Autonomy at the architecture level demands governance at the architecture level — not per-function safety alone, but system-wide controls that apply regardless of which agent or framework is acting. Five mechanisms form the backbone. Capability scoping restricts each agent to the minimum tools and permissions its goal requires — the agent-level expression of least privilege, extending tutorial 12's per-function scoping to the whole agent. A policy engine checks a proposed action against defined rules (spending limits, allowed operations, required approvals) before it executes, centralizing rules that would otherwise be duplicated across every agent's code.

Sandboxing runs an agent's actions in a restricted environment — a scoped execution context, a limited service account, a network-isolated boundary — so a mistake or a successfully manipulated agent cannot reach beyond that boundary. An audit trail durably records every agent decision and action, in order, for review, debugging, and compliance — the system-wide counterpart to tutorial 18/19's step-by-step logging. And a kill switch gives operators a way to immediately halt an agent or the whole agent system's activity when behavior is unsafe or out of control, independent of whatever loop or termination condition the agent's own code relies on.

8 Deep Dive 4: Converting a Traditional AI Pipeline into an Agent-Based System

A traditional AI pipeline runs a fixed sequence — for example, tutorial 15's RAG flow: embed the question, search, build a grounded prompt, generate an answer — the same steps every time. Converting it into an agent-based system does not mean throwing the pipeline away; it means identifying which fixed steps should become a decision an agent makes, and which should stay as tools the agent can call. The pipeline's steps often become exactly the agent's tool set.

// Every question follows the identical sequence, regardless of what it actually needs.
async Task<string> AnswerAsync(string question, CancellationToken ct)
{
    var passages = await RetrieveAsync(question, k: 5, ct);         // always retrieves
    var prompt = BuildGroundedPrompt(question, passages);          // always the same prompt shape
    return await GenerateAsync(prompt, ct);                        // always one generation call
}

public sealed class KnowledgePlugin
{
    [KernelFunction, Description("Searches the knowledge base for passages relevant to a question.")]
    public Task<string> SearchKnowledgeBase(string question) => RetrieveAsJsonAsync(question);

    [KernelFunction, Description("Looks up a specific order's live status. Use for order questions, not general knowledge.")]
    public Task<string> GetOrderStatus(string orderNumber) => OrderRepository.FindJsonAsync(orderNumber);

    [KernelFunction, Description("Asks a clarifying question when the user's request is ambiguous.")]
    public string AskClarification(string question) => question;   // surfaced back to the user
}

// The agent now DECIDES whether to search knowledge, check an order, ask a
// clarifying question, or some combination -- instead of always doing all three.
ChatCompletionAgent supportAgent = new()
{
    Instructions = "Help the user. Use SearchKnowledgeBase for policy/how-to questions, " +
                   "GetOrderStatus for a specific order, and AskClarification if the request is unclear.",
    Kernel = kernelWithKnowledgePlugin
};

Do this incrementally and keep the old pipeline available as a fallback during rollout: run both in parallel behind a feature flag, compare outcomes, and only fully cut over once the agent version's behavior is trusted on real traffic. This is a migration strategy, not a one-shot rewrite, and it mirrors tutorial 18's testing advice — test the intended path (agent picks the right tool) and the edge cases (ambiguous input, tool failure) before trusting the migration in production.

9 Ecosystem and Tools

Agent-first architecture is a design layer above any specific framework — the registry, communication model, and governance controls here would look similar whether the agents underneath are built in Semantic Kernel, AutoGen, or hand-rolled. That is deliberate: architecture decisions should outlive framework choices.

10 Use Cases

• Incident response: log-analysis, metrics, and diagnosis agents collaborate via a blackboard to converge on a probable root cause faster than a fixed runbook.
• Customer support platform: a triage agent uses direct messaging or a message bus to route conversations to specialist agents (billing, technical, account) as needs are discovered.
• Enterprise workflow automation: a traditional multi-step approval pipeline is converted into an agent that decides which checks are relevant per request, cutting unnecessary steps for simple cases while keeping the full sequence for complex ones.
• Regulated financial operations: heavy governance (policy engine, sandboxing, audit trail, kill switch) wraps a lending or transaction-review agent so autonomy doesn't outrun compliance requirements.
• Research/analysis assistants: multiple specialist agents (data-gathering, synthesis, critique) communicate via a message bus, each addable independently as new specialties are needed.
• Legacy RAG modernization: an organization's existing fixed retrieve-then-answer pipeline is incrementally converted into an agent that can also check live systems, ask clarifying questions, or escalate — without discarding the working retrieval code.

The common thread: agent-first architecture pays off when a system's tasks are open-ended and judgment-dependent, involve multiple specialized capabilities that need to combine flexibly, or must evolve incrementally from something that already works.

11 Code Examples

These examples show an agent registry, a policy-engine gate around an agent action, and an audit-trail wrapper — the architecture-level scaffolding this tutorial's concepts need in code.

public sealed record AgentDescriptor(string Name, string Responsibility, Func<string, Task<string>> Invoke);

public sealed class AgentRegistry
{
    private readonly Dictionary<string, AgentDescriptor> _agents = new();

    public void Register(AgentDescriptor descriptor) => _agents[descriptor.Name] = descriptor;

    public AgentDescriptor? FindFor(string taskDescription) =>
        _agents.Values.FirstOrDefault(a => TaskMatchesResponsibility(taskDescription, a.Responsibility));

    // A real system might use embeddings/semantic match here instead of simple heuristics.
    private bool TaskMatchesResponsibility(string task, string responsibility) =>
        task.Contains(responsibility, StringComparison.OrdinalIgnoreCase);
}

public interface IPolicyEngine
{
    PolicyResult Evaluate(AgentAction action);
}

public sealed record AgentAction(string AgentName, string Operation, decimal? Amount, string UserId);
public sealed record PolicyResult(bool Allowed, bool RequiresHumanApproval, string? Reason);

public sealed class RefundPolicyEngine : IPolicyEngine
{
    public PolicyResult Evaluate(AgentAction action)
    {
        if (action.Operation != "refund") return new(true, false, null);
        if (action.Amount is > 500m) return new(true, true, "Refunds over $500 require approval");
        return new(true, false, null);
    }
}

// The agent's action goes through the policy engine before executing.
var decision = policyEngine.Evaluate(new AgentAction("BillingAgent", "refund", 620m, userId));
if (decision.RequiresHumanApproval)
    await humanApproval.RequestAsync(decision.Reason!, action);
else
    await ExecuteRefundAsync(action);

async Task<string> InvokeWithAuditAsync(
    string agentName, string operation, Func<Task<string>> action, ILogger logger, string correlationId)
{
    logger.LogInformation("AUDIT {CorrelationId} {Agent} PROPOSED {Operation}",
        correlationId, agentName, operation);
    try
    {
        string result = await action();
        logger.LogInformation("AUDIT {CorrelationId} {Agent} SUCCEEDED {Operation}: {Result}",
            correlationId, agentName, operation, result);
        return result;
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "AUDIT {CorrelationId} {Agent} FAILED {Operation}",
            correlationId, agentName, operation);
        throw;
    }
}

12 Step by Step: Converting a RAG Pipeline into a Governed Agent

This walkthrough converts tutorial 15's fixed RAG pipeline into a small agent-first system with a registry, a communication model, and governance, following the migration sequence from deep-dive 4.

1. Start from a working retrieve-then-answer pipeline (tutorial 15) and identify its steps: retrieval, prompt construction, generation.
2. Wrap retrieval as a described native function (SearchKnowledgeBase) and identify at least one more capability worth adding that the old pipeline never had (e.g. GetOrderStatus) — this is the moment the system gains flexibility.
3. Create a ChatCompletionAgent (or AutoGen equivalent) whose instructions state the goal and name when to use each tool, replacing the old fixed sequence.
4. Register the agent in a simple AgentRegistry (Example 1) alongside a placeholder second agent (even a stub), and route an incoming request through the registry instead of calling the agent directly — this is your agent communication model in miniature.
5. Identify one action in the system that is consequential (e.g. anything with a dollar amount or irreversible effect) and add a policy-engine check (Example 2) in front of it.
6. Wrap every agent action with the audit-trail logger (Example 3), and confirm you can reconstruct a full decision trail from logs after a test run.
7. Add capability scoping explicitly: document, in code or configuration, exactly which tools each agent may use, and verify the agent cannot invoke a tool it wasn't given.
8. Add a kill switch: a simple flag or endpoint that, when set, causes the agent invocation path to short-circuit and refuse to act — test that it actually stops a mid-flight scenario.
9. Run the old pipeline and the new agent-based system side by side (behind a flag) on the same test questions, and compare: does the agent's flexibility change answers for the better, and does governance catch the scenarios it should?
10. Reflect on the checklist from deep-dive 1: was this task genuinely a good fit for agent-first, or did the conversion add complexity without proportional benefit? Both conclusions are valid outcomes of this exercise.

13 Limitations and Caveats

• Agent-first is not a universal upgrade: it trades predictability and testability for flexibility, and many systems (well-defined, stable operations) are better off staying request/response.
• Communication model choice has real operational cost: a message bus and blackboard pattern both add infrastructure (a broker, a shared store) and new failure modes (message loss, stale shared state) that direct messaging doesn't have.
• Governance mechanisms (policy engine, sandboxing, audit trail, kill switch) are necessary but not sufficient — each must actually be tested and maintained, or it provides false confidence rather than real safety.
• A policy engine only enforces the rules it has been given; it cannot catch a genuinely novel harmful action nobody anticipated writing a rule for.
• Sandboxing bounds damage but doesn't guarantee correctness — a sandboxed agent can still produce a wrong answer or waste resources within its boundary.
• Converting a pipeline to an agent is not free: it typically increases latency (more decision rounds), cost (more model calls), and debugging surface, so it should be justified by a genuine need for flexibility, not novelty.
• This tutorial's patterns (registry, policy engine, audit wrapper) are illustrative scaffolding, not a specific product or library — real systems often adopt an existing message-bus or policy-engine product rather than hand-rolling one, and exact class/library choices are outside this course's scope.
• Migrating incrementally (deep-dive 4) reduces risk but extends timelines; running old and new systems in parallel has its own maintenance cost during the transition.

14 Best Practices

• Make agents the exception, not the default: apply agent-first only to genuinely open-ended, judgment-requiring parts of a system, and keep the rest as ordinary, predictable services.
• Choose the communication model by actual coupling needs: direct messaging for small, stable agent sets; a message bus as the system grows or agents are added/replaced; a blackboard when multiple agents contribute partial findings toward one shared conclusion.
• Design governance in from the first agent action, not after an incident — capability scoping, a policy engine, sandboxing, an audit trail, and a tested kill switch are a package, not a checklist to satisfy individually.
• When converting a pipeline, wrap existing steps as tools first and preserve their tested behavior; introduce the agent as a thin decision layer on top rather than rewriting the underlying logic.
• Run old and new systems in parallel during migration and compare real outcomes before fully cutting over.
• Keep an explicit agent registry once a system has more than a couple of agents — implicit knowledge of 'which agent handles what' does not scale.
• Test governance controls directly and regularly (does the kill switch actually stop it, does the policy engine actually block the disallowed action) rather than assuming they work because the code compiles.
• Revisit the agent-first decision periodically: a task that was genuinely open-ended six months ago may have stabilized into a predictable pattern worth converting back to a fixed pipeline.

20 Summary

• Agent-first architecture makes agents — goal-owning, tool-using, decision-making components — the primary unit of functionality, replacing fixed request/response handlers for genuinely open-ended, judgment-requiring tasks only.
• Agent communication models — direct messaging, a message bus, and the blackboard pattern — trade coupling for flexibility differently, and the right choice depends on how stable the agent set is and whether interaction is request/reply or collaborative-and-cumulative.
• Governance for agentic systems layers five mechanisms — capability scoping, a policy engine, sandboxing, an audit trail, and a kill switch — each closing a gap the others leave open, designed in from the first agent action rather than retrofitted after an incident.
• Converting a traditional AI pipeline into an agent-based system means wrapping existing steps as tools and introducing an agent to choose among them, not rewriting working logic from scratch — rolled out in parallel with the old system before full cutover.
• None of this is a universal upgrade: the tutorial's repeated caution is to apply agent-first only where fixed sequences genuinely cannot capture the needed behavior, and to treat 'this task didn't need to be agentic' as a valid conclusion.
• These architectural lessons sit above and outlive any specific framework (Semantic Kernel, AutoGen, or otherwise) — they are the transferable judgment that framework fluency alone does not provide.

You now have the architectural vocabulary to decide not just how to build an agent, but whether and where agents belong in a system at all, how they should find and talk to each other as a system grows, and what governance autonomy demands before it reaches production. This is the layer above tutorials 17–19's frameworks — durable across whatever specific tools you use to implement it. With architecture and safety established, the course now turns to a concrete standard for one piece of this puzzle: how agents and tools describe themselves to each other in an interoperable way, which is exactly what the Model Context Protocol addresses next.

21 Next Steps

Next tutorial: Model Context Protocol (MCP) (model-context-protocol-mcp). Agent-first architecture raised the question of how agents and tools connect across a system; MCP is an open standard that addresses one important piece of that — packaging tools and context sources into reusable, interoperable servers that any compliant AI application can discover and use, rather than each application defining its own bespoke tool integrations.

• Practice: take one existing service in a project you control and explicitly decide, using deep-dive 1's checklist, whether it is a good agent-first candidate — write down the reasoning either way.
• Practice: build the AgentRegistry and RefundPolicyEngine sketches from the code examples, then write a test that deliberately tries to invoke an out-of-scope tool and confirms it's blocked.
• Practice: implement and then directly test a kill switch against a simulated in-flight agent loop, confirming it actually halts mid-execution rather than only at a natural boundary.
• Practice: complete the RAG-to-agent conversion walkthrough end to end, including running both versions in parallel on the same test set and recording the latency/cost/quality comparison.
• Read: general software architecture material on the blackboard pattern and publish/subscribe messaging, plus any current guidance on responsible AI governance frameworks, since this tutorial's five governance mechanisms map onto established patterns from those fields.