Processing Documents, Audio, and Video with Azure Content Understanding

A real business case rarely arrives as one clean document. It may include a PDF form, scanned evidence, screenshots, a call recording, and a video clip—all describing different parts of the same situation.

The hard part is not generating a summary. It is extracting structured data with enough evidence and confidence to drive a real process without hiding uncertainty.

This session builds an end-to-end case-intake pipeline in TypeScript using Azure Content Understanding. We will define a reusable schema, process multimodal content with an analyzer, and collect structured results across documents, images, audio, and video.

Then we will move beyond extraction. The pipeline will validate required fields, preserve supporting evidence, apply confidence gates, redact sensitive data, and route uncertain results to a person for review. We will also compare when Azure Document Intelligence or a custom LLM pipeline is the better fit based on content type, customization, cost, and operational risk.

Attendees will leave able to model a multimodal extraction schema, implement an analyzer workflow, design confidence and review boundaries, and select the appropriate Azure service for a production content pipeline.

Structured output is useful. Structured output with evidence, validation, and a recovery path is something a business process can trust.

Audience: Engineers, data practitioners, and architects building production content pipelines.
Format: 45–60-minute Azure-focused technical talk with live C# demonstrations.
Demo: A multimodal case file processed through schema extraction, validation, confidence gates, PII handling, and human review.
Evidence: Previously delivered at AI Community Day on December 5, 2025 as a 45-minute session.
Materials: Talk-specific repository, slides, and recording are not yet published.
Vendor scope: Microsoft-specific; uses Azure AI Content Understanding and compares adjacent Azure services.

From Vibes to Specs: Choosing the Right AI Coding Workflow

AI can turn a conversational prompt into a working feature. That is useful when you are testing an idea. It becomes risky when the code must survive security review, changing requirements, and a team that never saw the original conversation.

The problem is not vibe coding itself. The problem is using an exploration workflow for production work without recognizing where the workflow needs to change.

This session builds the same feature three ways. First, we use vibe coding to create a quick spike. Next, we add context engineering: repository instructions, domain documentation, API schemas, examples, and clear tool permissions. Finally, we make the work spec-driven with explicit contracts, acceptance criteria, implementation tasks, tests, and CI gates.

We will compare where each workflow saves time, what hidden work it creates, and when the additional structure is worth the cost. The result is not a ranking—it is a practical way to match the workflow to the risk and expected lifetime of the code.

Attendees will leave able to choose an AI coding workflow based on context, design useful instructions for an AI coding tool, and create a lightweight specification that produces reviewable code instead of an impressive but ownerless demo.

Not every task needs a specification. Every production change needs enough shared context for the team to own it.

Audience: Developers and engineering leads adopting AI coding workflows.
Format: 45–60-minute technical talk with one feature implemented three ways.
Demo: Vibe-coded spike → context-engineered revision → spec-driven pull request with tests and CI checks.
Take-home artifact: Workflow decision matrix and specification/checklist templates; talk-specific package is not yet published.
Vendor scope: Vendor-neutral workflow; examples can be demonstrated with common AI coding assistants.

How to Test AI Features Before Your Users Do

Your AI feature worked yesterday. Today, a prompt change, model upgrade, or retrieval tweak quietly reduced answer quality—and every traditional test still passes.

Unit and integration tests can verify code paths, API contracts, and deterministic behavior. They cannot tell you whether an answer is grounded, whether important information was missed, or whether a response became less useful after a change. That requires application-specific evals.

Using an anonymized internal knowledge assistant, this session starts with a small application that appears to work. We will expose three realistic failure modes: unsupported claims, missed key information, and brittle behavior after a change. Then we will turn those failures into a lightweight eval suite.

The demo covers a compact golden dataset, pass/fail checks, rubric-based scoring, pairwise comparison, and a regression workflow for prompt, model, and retrieval changes. We will also trace failed cases to determine whether the problem came from retrieval, generation, or the surrounding system design.

Attendees will leave able to distinguish benchmarks from application evals, create a small but useful dataset, choose an appropriate scoring method, and add repeatable quality checks to an existing delivery workflow.

You cannot make every response deterministic. You can make quality visible before your users find the regression.

Audience: Software engineers and technical leads building LLM or RAG features.
Format: 45–60-minute conference talk with live demonstrations. This reusable profile is not the 120-minute workshop version.
Demo: An anonymized knowledge assistant, three failure modes, a golden dataset, scoring, and a regression workflow.
Evidence: Accepted for The Commit Your Code Conference 2026.
Materials: Talk-specific repository, slides, and recording are not yet published.
Vendor scope: Vendor-neutral testing patterns; implementation examples use C#/.NET.

The Agent Is Still Working: Designing UI for Progress, Uncertainty, and Control

Your agent says it is working. Is it calling a tool, waiting for approval, recovering from a failure, or stuck?

Traditional loading indicators are not enough for long-running agent workflows. Users need useful progress, clear choices, safe interruption points, and a way to recover when part of the run fails.

This session shows how to design a frontend around the agent lifecycle. In a live Next.js demo, we will evolve a basic chat interface into an application that streams progress, displays structured tool results, requests approval before side effects, and lets the user cancel, retry, or resume work.

CopilotKit and the Vercel AI SDK provide the implementation example. AG-UI carries agent events and shared state. A2UI demonstrates host-rendered declarative interfaces, while MCP Apps demonstrates interactive views returned by tools. The goal is not to use every protocol at once, but to understand which frontend problem each one addresses.

Attendees will leave able to:

- Model an agent run as visible UI states
- Show useful progress without exposing internal reasoning
- Render structured results instead of long chat messages
- Design approval, cancellation, retry, and recovery interactions
- Choose when application components, declarative UI, or tool-provided views fit

The frontend should not make an agent look busy. It should help the user understand what is happening and what they can do next.

Which Agent Runtime Fits the Job? SDKs, Harnesses, and Frameworks Compared

Teams often choose an agent framework before deciding what the runtime must own. That reverses the decision—and usually adds complexity before the first workflow reaches production.

The real question is not which product has the longest feature list. Does the application need a small SDK around one tool-using loop, a harness that manages context and execution, or a framework that coordinates multiple agents and services? Each layer solves a different problem.

This session starts with the minimum anatomy of an agent: model, tools, memory, state, and an action loop. From there, we will compare the OpenAI Agents SDK, GitHub Copilot SDK, and Microsoft Agent Framework against the same workload requirements.

A single tool-using task will be mapped across all three approaches. We will compare lifecycle control, tool boundaries, persistence, observability, deployment, and lock-in. The shared scenario keeps the differences concrete and exposes where each option adds useful structure—or structure the application does not need.

Attendees will leave with a vocabulary for separating SDKs, harnesses, and frameworks, a decision matrix for comparing runtime options, and a repeatable way to choose based on workload constraints rather than product familiarity.

Start with the job. Then choose the smallest runtime that can operate it reliably.

Audience: Developers and architects selecting an agent stack.
Format: 45–60-minute comparison talk with code excerpts and one shared scenario.
Demo: The same tool-using task mapped across Claude Agent SDK, GitHub Copilot SDK, and Microsoft Agent Framework.
Materials: Talk-specific decision matrix, repository, slides, and recording are not yet published.
Vendor scope: Comparative and vendor-neutral; Azure deployment implications are identified explicitly.

Run AI in the Browser: Private, Offline Inference with WebGPU

Some AI features should not send every input to a server. The data may be sensitive, the network may be unreliable, or the interaction may need to respond without a round trip.

On supported devices, the browser has enough compute to run useful AI models locally. After the model assets are downloaded, inference can stay on the device—changing the privacy, latency, cost, and offline architecture of the application.

This session runs three workloads directly in a browser tab: text generation, image classification, and semantic search. Using Transformers.js, ONNX Runtime, WebGPU, and a WASM fallback, we will build an inference flow that continues working without an inference backend.

The demos are only part of the decision. We will measure the constraints that determine whether a model belongs in the browser: download size, quantization, startup time, memory pressure, hardware differences, and browser support. We will also identify when local inference adds more complexity than value and a server remains the better answer.

Attendees will leave able to select browser-appropriate models, choose between WebGPU and WASM execution, design an offline-capable inference flow, and explain the privacy and operational tradeoffs of client-side AI.

Not every model belongs in the browser. Some useful features do—and web developers can build them today.

Audience: Web developers and architects evaluating client-side AI.
Format: 45–60-minute technical talk with live browser demonstrations.
Demo: Local text generation, image classification, and semantic search with no inference backend.
Technology reference: https://github.com/huggingface/transformers.js
Evidence: New reusable session; currently in evaluation for Live! 360 Tech Con Orlando 2026.
Materials: Talk-specific repository, performance notes, slides, and recording are not yet published.
Vendor scope: Vendor-neutral web standards and open-source runtimes.

De-Agenting a Workflow: Replace AI Where Deterministic Code Works Better

The agent works—but every run costs more, behaves differently, and is difficult to debug.

In this session, we will refactor an over-agented expense-approval workflow. The original agent reads receipts, interprets policy, selects an approver, updates records, and handles exceptions.

We will replace each responsibility with the simplest reliable mechanism:

- Structured extraction for receipt data
- Deterministic rules for policy checks
- A workflow engine for routing and approvals
- Human review for high-risk exceptions
- An agent only where bounded judgment adds value

The comparison will show how each change affects reliability, latency, cost, security, and observability.

Attendees will leave with a practical method for reducing unnecessary autonomy without removing useful AI. The goal is not to eliminate agents. It is to make every remaining agentic decision justify its complexity.

Your Agent Needs More Than Chat: Designing Interactive Agent UIs

Your agent knows what it is doing. Your interface still shows a spinning chat bubble.

When an agent needs to show progress, request consent, collect structured input, or return an interactive result, many teams connect custom UI components to tool calls one workflow at a time. It works—until the agent, interface, and application state stop agreeing.

This session compares three emerging approaches to that problem. AG-UI streams agent state, events, and tool progress into the application. A2UI lets an agent describe a trusted interface using structured data. MCP Apps allows a tool to return an interactive experience inside a sandboxed surface. They overlap, but they solve different parts of the interaction layer.

In one end-to-end expense-approval demo, we will connect all three approaches. The interface will stream the agent’s plan, pause before a sensitive action, render a structured approval form, and return an interactive audit view showing what happened.

Attendees will leave able to explain where these protocols overlap, choose the right boundary for state and UI generation, implement consent-first actions, and design agent interfaces that remain testable and secure.

The goal is not to put every protocol into one application. It is to understand which piece fits the interaction you need.

Audience: Front-end, full-stack, and agent developers building interactive web applications.
Format: 45–60-minute technical talk with one end-to-end live demo.
Demo: An expense-approval agent using AG-UI state events, an A2UI form, and an MCP App audit view.
Technology reference: https://github.com/ag-ui-protocol/ag-ui
Materials: Talk-specific repository, slides, and recording are not yet published.
Vendor scope: Protocol-focused and vendor-neutral; web examples use React and TypeScript.

Break the Agent on Purpose: Failure Injection, Recovery, and Human Escalation

The model is not the only thing that fails.

APIs time out. A tool completes after the agent gives up. Retries repeat an action with side effects. State becomes stale, and approval steps disappear down the wrong execution path.

This session shows how to break an agent on purpose—and use each failure to make the system safer. In a live demo, we will run a tool-using agent through a series of production failure drills: delayed responses, malformed tool output, partial success, duplicate requests, unavailable dependencies, and interrupted workflows.

For each failure, we will add one recovery pattern and test the result. That includes bounded retries with backoff, idempotency keys, durable checkpoints, compensating actions, circuit breakers, degraded modes, and human escalation. We will use traces to verify the path taken, not only the final response.

Attendees will leave able to:

- Map failures across models, tools, state, and infrastructure
- Decide when to retry, compensate, stop, or escalate
- Protect side-effecting tools from duplicate execution
- Preserve workflow state across interruptions
- Turn failure drills into repeatable regression tests

Production reliability does not come from adding every guardrail at once. Start with the failures that matter, make the recovery behavior explicit, and prove that it works.

Context Has a Budget: Measure What Your Agent Uses Before Adding More

More context feels safer. Include the entire conversation. Retrieve ten documents instead of three. Add everything the user has ever done.

Then the answers get slower, more expensive, and sometimes worse.

In this session, we will run a controlled experiment against a support assistant. We will ask the same questions while changing only the context strategy: full conversation history, fixed-size retrieval, reranked retrieval, summaries, and explicit application state.

For each version, we will measure answer quality, groundedness, latency, and token usage. Then we will deliberately introduce irrelevant documents, stale memory, and contradictory instructions to see where the system fails.

The demo will show how to:

- Build a small evaluation dataset for context decisions
- Separate conversation history, retrieved knowledge, and application state
- Detect when additional context reduces answer quality
- Compare fixed retrieval with filtering and reranking
- Summarize older history without losing critical facts
- Exclude sensitive or irrelevant information by design
- Create a context budget based on evidence instead of intuition

This is not a session about finding the perfect context-window size. It is about treating context as an engineered input that can be tested, measured, and constrained.

Attendees will leave with a repeatable experiment for deciding what their AI system needs to know—and what it should never receive.

Engineering Agent Loops: Tool Use, Verification, Events, and Termination

Most agent demos end after one successful prompt or tool call. Production agents keep going—and that is where the difficult failures begin.

Once an agent enters a loop, it must select tools, evaluate progress, retry failed work, react to external events, preserve state, and decide when to stop. A weak loop can repeat the same action, lose progress between turns, or silently burn time and tokens without getting closer to the goal.

This session compares four practical loop patterns: a tool-use loop that runs until a goal condition is met, a verification loop that grades and retries work, an event-driven loop that resumes from external signals, and an optimization loop that improves behavior using traces. We will compare their latency, token cost, persistence requirements, and characteristic failure modes.

Then we will build a persistent goal-condition loop in C#/.NET. We will deliberately trigger a non-termination failure, trace why the loop cannot finish, and add evaluation, retry, and budget boundaries that stop it safely.

Attendees will leave able to recognize the loop hidden inside an agent product, choose a pattern based on the job, implement explicit state and termination conditions, and diagnose loops that silently waste time or tokens.

Reliable agents do not keep going forever. They know when the work is done.

Audience: Developers who understand basic prompting and tool calling and now need reliable agent control flow.
Format: 45–60-minute technical talk with a live C#/.NET build.
Demo: Persistent goal-condition loop, per-turn evaluator, deliberate non-termination failure, and budget-based termination.
Evidence: New session; no prior public delivery.
Materials: Talk-specific repository, state diagram, slides, and recording are not yet published.
Vendor scope: Framework-agnostic loop patterns with a C#/.NET implementation.

Your Tests Pass. Does Anyone Understand the Code?

Your tests pass. The code compiles. The pull request looks clean. But can anyone on the team explain why it works?

A common failure pattern starts with AI-generated code that has good naming, full coverage, and every check green. It is approved quickly. Months later, the module breaks and nobody can explain its design decisions because the intent lived in an AI conversation that was never preserved.

This is not only a hypothetical risk. In a randomized study of 52 developers learning a new library, the AI-assisted group did not finish significantly faster and scored 17% lower on a follow-up comprehension test. The strongest AI users asked conceptual questions and deliberately rebuilt their understanding instead of delegating the entire task.

This session examines how AI-authored code fails differently: plausible duplication, hidden assumptions, unnecessary abstractions, brittle tests, and lost intent. Through a pull-request review exercise, we will expose these failure modes and apply a practical comprehension checklist.

Attendees will leave able to identify AI-specific review risks, preserve the reasoning behind implementation decisions, and make explainability an explicit quality signal before code is merged.

AI can help write the code. Your team still needs to understand it.

Audience: Software engineers, reviewers, and engineering leaders using AI coding tools.
Format: 45–60-minute evidence-driven talk with a pull-request review exercise.
Demo: Review an illustrative AI-authored module, expose five failure modes, and apply a comprehension checklist.
Research: Anthropic’s randomized developer study: https://www.anthropic.com/research/AI-assistance-coding-skills
Materials: Talk-specific checklist, slides, and recording are not yet published.
Vendor scope: Vendor-neutral.

Your Agent Failed Between Spans: Tracing Tool Calls, Decisions, and Recovery with OpenTelemetry

Your agent passed every test and shipped. Two weeks later, someone asks why it approved something it should not have—and the logs cannot explain the decision.

Traditional monitoring can tell you whether the service was healthy. Latency, error rate, and uptime matter, but they do not show which context the agent received, which tools it called, how decisions changed across handoffs, or where a multi-step workflow drifted.

This session shows how to build an agent-observability layer with OpenTelemetry. We will start with a live failure that looks normal in the application logs. Then we will trace the request across model calls, tool execution, and agent handoffs until the reason for the bad decision becomes visible.

Along the way, we will capture the signals that matter: inputs and outputs at reasoning boundaries, tool arguments and results, token cost, latency, errors, and the evidence used to make a decision. We will also examine what not to capture—and why observability should not become indiscriminate prompt logging.

Attendees will leave able to distinguish infrastructure monitoring from agent tracing, instrument an agent pipeline, troubleshoot a failed decision, and define the minimum observability required before an agent reaches production.

If you cannot explain what the agent did, you are not ready to operate it.

Audience: Engineers and technical leads operating agent systems in or near production.
Format: 60–75-minute technical talk with a live tracing demonstration.
Demo: Microsoft Agent Framework on Azure instrumented with OpenTelemetry; concepts transfer to other runtimes.
Materials: Talk-specific repository, slides, and recording are not yet published.
Vendor scope: Vendor-neutral observability model with a Microsoft implementation.

How Much Should This Agent Be Allowed to Do? A Framework for Autonomy and Control

Your agent can take action without waiting for a person. That sounds useful—until it approves the wrong refund, uses the wrong permission, or makes a decision nobody can explain.

Most teams respond with one of two extremes. They require approval for every step or allow the agent to act freely. Neither approach works when the task, risk, and cost of failure change.

This session introduces five levels of agent autonomy: operator, collaborator, consultant, approver, and observer. The framework treats autonomy as a per-task design choice—not a platform-wide setting. We will compare what changes in speed, permissions, evidence, human oversight, recovery, and the cost of a mistake. The comparison shows why a workflow that is safe for one decision may be unacceptable for another.

Attendees will leave able to classify agent workflows using the five levels, match autonomy to a task’s risk profile, and design clear permission and approval boundaries. They will also learn how to identify agents with too much—or too little—freedom.

The goal is not maximum autonomy. It is deliberate, observable control.

Audience: Engineers and engineering leaders designing agents that can take actions.
Format: 60–75-minute framework talk with a live comparative demo.
Demo: One refund request executed at three autonomy levels with different permission, evidence, and approval boundaries.
Evidence: New session
Materials: Talk-specific assessment worksheet, repository, slides, and recording are not yet published.
Vendor scope: Vendor-neutral design framework.

AI Wrote the Code Faster. Did the Team Deliver Better?

AI wrote the change faster. The review took longer. Production became less stable. Was the team actually more productive?

Research gives conflicting answers because it measures different things. Controlled studies have found faster task completion and higher output in some settings. METR found experienced open-source maintainers were slower with early-2025 AI tools. DORA reports higher AI adoption alongside both greater throughput and greater instability.

These results are not interchangeable. A faster coding task does not automatically improve team flow, software delivery, or customer outcomes.

This session turns that measurement problem into a practical scorecard. We will connect four layers: developer effort and comprehension; team flow, review latency, and rework; delivery throughput and stability; and product outcomes. We will examine how to establish a baseline, segment results by task type, and detect when AI simply moves work downstream.

We will also challenge seductive metrics such as lines of code, pull-request count, and suggestion acceptance. They can prove that people are using AI without proving that the investment created value.

Attendees will leave able to evaluate AI productivity claims, choose a balanced set of measures, and run a useful experiment with their own team.

Measure the system, not the typing.

Audience: Engineering leaders, developer-productivity teams, and senior engineers measuring AI adoption.
Format: 20–45-minute evidence-driven leadership talk.
Example: Build a measurement scorecard that pairs delivery outcomes with review, rework, durability, and comprehension signals.
Research: METR randomized trial: https://arxiv.org/abs/2507.09089
Vendor scope: Vendor-neutral.

Before You Ship That Agent: Production Design Decisions to Consider

Every agent demo has the same quiet moment: it works, on the happy path, with a friendly audience. Production has no happy path.

A timeout may have already charged a card. A price may change while an approval waits. A model may be persuaded to act outside its intended authority. The orchestration layer may scale while the systems behind it collapse.

This session examines ten production design decisions engineers often underestimate when moving an AI agent beyond the demo. Where should model judgment end and software-enforced invariants begin? How should the system represent an unknown outcome? Which facts must be revalidated before an approved action resumes? How much authority should the agent receive?

Using real code patterns rather than a live demo, we will examine idempotency keys, durable action records, approval versioning, scoped permissions, concurrency limits, containment boundaries, and structured tracing. Each pattern is tied to a failure mode that appears after shipping.

Attendees will leave able to:

- Separate model judgment from software-enforced rules
- Implement safe retries and approval revalidation for irreversible actions
- Evaluate an agent’s authority envelope and containment boundaries
- Use a ten-check release-review card to assess production readiness

Built for engineers and engineering leads shipping—or preparing to ship—an agent past the demo stage.

Audience: Engineers and engineering leads shipping or preparing to ship AI agents. Format: 45–60-minute technical talk using real code patterns and a ten-check release-review card; no live demo. Vendor scope: Vendor-neutral.

The Technical Debt AI Agents Create: Prompt Drift, Phantom Abstractions, and Unreviewable Diffs

An agent can solve the ticket, pass the tests, and still leave the codebase harder to change. It invents an abstraction that matches nothing else, duplicates logic that already exists three files away, and hides both inside a diff too large to review well. Nobody wrote obviously bad code. The debt got in anyway.

This is technical debt when AI coding agents write a growing share of the codebase. The session names three recurring forms: prompt drift, where changing instructions produce inconsistent implementation choices; phantom abstractions, which look reusable but encode assumptions the system does not share; and unreviewable diffs, where volume defeats meaningful human review.

A before-and-after code walkthrough will trace one agent-generated change from passing tests to measurable maintenance cost. We will compare the result with Martin Fowler's technical debt quadrant, then use churn, duplication, ownership, and diff-risk signals to catch what static analysis misses. We will also define review boundaries based on change size, reversibility, and blast radius instead of one flat rule.

Attendees will leave able to recognize these debt patterns early, measure their spread, design smaller reviewable agent tasks, and explain why compiled and tested is necessary—but not the same as maintainable. This is not an argument against AI-assisted coding. It is a field guide for teams already living with agents in the codebase.

Audience: software engineers, tech leads, and engineering managers using AI-assisted coding tools. Format: 50-minute technical session with a code walkthrough; no live demo required. Vendor-neutral.

Agent Systems Are Distributed Systems: Reusing the Failure Patterns We Already Know

One agent retries a timed-out call with no backoff. Another accepts a fabricated result as fact. A third updates shared state after the workflow has already moved on. If that sounds like a distributed-systems problem, it is. The job titles changed. The failure modes did not.

Multi-agent systems inherit partial failures, duplicate execution, stale state, backpressure, and cascading outages. This session maps the patterns engineers already use in distributed systems onto agent-to-agent workflows: idempotency keys for safe retries, circuit breakers for failing dependencies, compensating actions for partially completed work, and explicit ownership for shared state.

A small multi-agent pipeline provides the walkthrough. First, one failed call triggers retries and inconsistent state across the workflow. Then we contain the same failure with bounded retries, idempotent operations, circuit breaking, and observable handoffs. We will also compare orchestration with choreography and show where each makes recovery easier—or harder.

Attendees will leave able to explain why multi-agent workflows fail like distributed systems, design safer agent-to-agent calls, choose a coordination model based on failure and recovery needs, and reason about consistency without pretending every agent sees the same world at the same time.

No framework is required. The goal is to apply proven engineering patterns before a small agent failure becomes a system-wide one.

Audience: mid-to-senior engineers and architects. Tracks: AI Agents & Workflows, Architecture, Programming Principles. Format: adaptable to 30, 45, or 60 minutes with a code walkthrough. Vendor-neutral.

Your Architecture Assumed a Human Was Driving: Redesigning Systems for Autonomous Actions

Your API returns a timeout. A human pauses, checks state, and decides whether to try again. An autonomous agent may retry immediately, use every permission it has, and keep going long after the original assumption stopped being true.

Many APIs were designed with a human somewhere near the loop—someone who can interpret an ambiguous error, notice an unexpected result, or stop the workflow. Agent callers turn those assumptions into architecture risks.

This session shows how to redesign an existing API boundary for autonomous callers. A before-and-after walkthrough will add idempotency keys and operation status for unknown outcomes, rate and cost budgets for retries, least-privilege scopes for bounded actions, structured errors with recoverable next steps, and traces that connect model decisions to API effects. We will also separate actions that can run unattended from those that require approval or revalidation.

Attendees will leave able to identify human-in-the-loop assumptions hidden in REST and RPC APIs, contain the blast radius of agent mistakes, design retries that do not duplicate irreversible work, scope permissions around actions instead of broad roles, and audit an API for agent readiness.

No agent framework is required. The goal is an API that stays predictable whether the caller is a person, a script, or an autonomous workflow.

Audience: mid-to-senior engineers and architects. Tracks: Architecture, Software Quality, AI Agents & Workflows. Format: adaptable to 30, 45, or 60 minutes with a before-and-after API walkthrough. Vendor-neutral.