Learn AI in Bits

This episode walks through the architecture of an agent on Microsoft Foundry, using a small IT help desk agent as the running example: a web front end, a backend that authenticates with Microsoft Entra ID, a Foundry agent running a GPT-5 deployment, and one custom tool that looks up a support ticket. Rather than a step-by-step build, it stays at the level of what each piece is and why it's there — the authentication approach that avoids API keys, the difference between a model and an agent, how the tool-calling loop works, the identities and permissions involved once an agent starts taking actions, and where a Foundry-managed prompt agent gives way to a fully hosted one.

It also covers what separates a demo from something production-ready: keeping the agent's definition in source control rather than the portal, building an evaluation dataset instead of testing by hand, watching what an agent does once it's live, and treating anything a tool retrieves as untrusted data rather than a trusted instruction.

Useful for anyone — technical or not — who wants a clear mental model of what "an agent" is made of, without needing to write any of the code themselves.

Sources & References

Quickstart: Create a prompt agent, Microsoft Foundry docs — https://learn.microsoft.com/azure/foundry/agents/quickstarts/prompt-agent

Use function calling with Microsoft Foundry agents (Python), Microsoft Foundry docs — https://learn.microsoft.com/azure/foundry/agents/how-to/tools/function-calling

Role-based access control for Microsoft Foundry — https://learn.microsoft.com/azure/foundry/concepts/rbac-foundry

Agent evaluators, Microsoft Foundry docs — https://learn.microsoft.com/azure/foundry/concepts/evaluation-evaluators/agent-evaluators

Built-in evaluators reference, Microsoft Foundry docs — https://learn.microsoft.com/azure/foundry/concepts/built-in-evaluators

Voice narration is AI-generated.

Why are developers saying Claude Opus 5 sucks when Anthropic's benchmarks describe it as one of the strongest models available? This episode examines the gap between benchmark capability and developer experience, focusing on complaints about over-engineering, instruction following, excessive autonomy, observability, and reliability.

REFERENCES

Anthropic — Introducing Claude Opus 5

https://www.anthropic.com/news/claude-opus-5

Anthropic — Claude / Opus

https://www.anthropic.com/claude/opus

Anthropic — Newsroom

https://www.anthropic.com/news

GitHub — Claude Code Issue #87491: Opus 5 treats direct instructions as negotiations

https://github.com/anthropics/claude-code/issues/87491

GitHub — Claude Code Issue #85395: Opus 5 regression in following instructions

https://github.com/anthropics/claude-code/issues/85395

GitHub — Claude Code Issue #85633: Opus 5 fabricates requirements and acts without permission

https://github.com/anthropics/claude-code/issues/85633

GitHub — Claude Code Issue #84933: Long Opus 5 agentic turns with limited visible assistant text

https://github.com/anthropics/claude-code/issues/84933

Reddit — Claude has started over-engineering every task

https://www.reddit.com/r/ClaudeAI/comments/1vod9ri/claude_has_started_overengineering_every_task/

ExplainX — Claude Opus 5 Over-Engineering: Reddit Reaction

https://explainx.ai/blog/opus-5-over-engineering-reddit-reaction-august-2026

Voice narration is AI-generated.

Claude Code gives developers five different places to put an instruction: a CLAUDE.md file, a Skill, an MCP connection, a Hook, or a permission setting. It is easy to shove everything into CLAUDE.md because it is the most familiar option, and just as easy to end up with a bloated file that Claude follows inconsistently. This episode builds a practical map for deciding which mechanism fits a given piece of information or behavior.

The episode covers CLAUDE.md as the home for persistent, project-wide guidance, loaded at the user, project, and local scopes plus nested directories, with a .claude/rules folder for instructions scoped to specific file paths. It explains Skills as reusable procedures stored in a SKILL.md file, where the body only loads into context when the Skill is used or judged relevant, making them a better fit for longer workflows than CLAUDE.md. It walks through MCP, or Model Context Protocol, using a Jira ticket example (looking up and updating issue ENG-4521) to separate a project's ticket-handling instructions, a reusable ticket-preparation workflow, and the underlying connection to Jira itself into their three respective layers. Hooks are covered as automated actions that run at defined points in Claude Code's lifecycle, whether as shell commands, HTTP calls, or prompt-based checks, with a TypeScript formatter Hook as the example. Permissions are explained as the layer that is enforced by the client regardless of what Claude decides, unlike CLAUDE.md's guidance-only instructions, and the episode notes when a PreToolUse Hook is the right tool for a hard restriction.

A worked example, a project called Shop, shows all five layers working together: a root CLAUDE.md with TypeScript and testing conventions, a path-scoped backend rule, a review-payment-code Skill, MCP connections to Jira and Postgres, a test-running Hook, and permissions blocking production credentials. The episode closes on why the separation is worth maintaining: CLAUDE.md content loads into every session's context whether it is needed or not, and Anthropic recommends keeping each file under roughly two hundred lines, since longer files consume more context and get followed less reliably.

Useful for anyone setting up or maintaining a Claude Code project who wants instructions Claude follows, rather than one oversized file competing with itself.

Sources & References

How Claude remembers your project, Claude Code docs — https://code.claude.com/docs/en/memory

Extend Claude with skills, Claude Code docs — https://code.claude.com/docs/en/skills

Connect Claude Code to tools via MCP, Claude Code docs — https://code.claude.com/docs/en/mcp

Hooks reference, Claude Code docs — https://code.claude.com/docs/en/hooks

Claude Code settings, Claude Code docs — https://code.claude.com/docs/en/settings

Voice narration is AI-generated.

A general AI assistant can summarize a contract in seconds. Getting it to apply a law firm's own playbook, follow jurisdiction-specific rules, and work inside the systems where a case lives is a different problem, and closing that gap is what vertical AI agents are built for. This episode explains what a vertical agent is, how it differs from a general-purpose model like Gemini, Claude, or GPT, and why the specialization increasingly lives in the system wrapped around the model rather than in the model itself.

The episode walks through Google's Gemini Enterprise for Legal, announced August 25, 2026, as a detailed example of that architecture: purpose-built skills for contract review, regulatory tracking, and legal research, secure integrations with tools lawyers already use including iManage, NetDocuments, and e-discovery platforms, and permission handling that carries over a firm's existing access controls instead of flattening them. It also covers Google's privacy claim that client data and playbooks are never used to train its foundation models.

Three other companies illustrate the same pattern outside law. Ambience Healthcare builds its platform around reconciling medical records and generating specialty-accurate clinical documentation and coding. EvenUp positions itself as the leading AI platform for personal injury law firms, covering case work from intake through trial. Harvey describes its product as legal AI for law firms and corporate legal teams, spanning contract analysis, due diligence, compliance, and litigation.

The episode explains why narrow, workflow-specific AI can create measurable business value, since automation pays off most when it's applied to an entire process rather than a single question, while noting that vertical AI products aren't automatically protected from competition, because foundation model providers are building their own industry-specific tools. Listeners will come away understanding that calling a system a vertical agent says nothing about whether its underlying model was trained specifically for that industry; the specialization usually comes from retrieval, instructions, tool connections, permissions, and evaluations layered around a general-purpose model.

Useful for anyone trying to understand how AI agents are being deployed inside regulated, workflow-heavy industries like law, healthcare, and finance.

Sources & References

Introducing Gemini Enterprise for Legal, Google Cloud Blog — https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-for-legal

Ambience Healthcare — https://www.ambiencehealthcare.com/

EvenUp Law — https://www.evenuplaw.com/

Harvey — https://www.harvey.ai/

Voice narration is AI-generated.

Claude Code's CLAUDE.md file is supposed to make every coding session smarter, but load it up carelessly and it does the opposite: burying the instructions that matter under everything else you've dumped in over time. This episode is a practical walkthrough of how CLAUDE.md actually works and how to keep it from getting out of hand.

The episode covers where these files live in Claude Code's memory hierarchy: a personal file in your home directory, a project file shared through source control, a gitignored CLAUDE.local.md for personal preferences, and an organization-wide managed policy file IT can push to every developer's machine, and how they combine. Nested CLAUDE.md files inside subdirectories like backend or backend/payments don't override their parent. Claude Code concatenates every discovered file into context, with broader instructions loaded first and more specific ones last, so contradictory rules across files can leave Claude with competing guidance instead of a clean override.

It also draws a distinction most CLAUDE.md advice skips: auto memory, the separate system where Claude Code writes its own notes based on corrections and preferences you give it as you work, versus CLAUDE.md, which only holds what you deliberately write. Mixing the two is one reason files balloon. Other practical guidance covered includes Claude Code's own recommendation to keep each CLAUDE.md under roughly two hundred lines, the .claude/rules folder for instructions scoped to specific file paths, skills for procedures that only need to load when relevant, the @ import syntax and why it doesn't actually shrink context, and the /init and /context commands for generating and auditing memory files. The episode closes on a point worth remembering on its own: CLAUDE.md is guidance the model tries to follow, not an enforced boundary, and anything that has to be blocked regardless of what Claude decides belongs in a hook or a permission setting instead.

Useful for anyone running Claude Code day to day who wants their CLAUDE.md file to actually get followed instead of ignored.

Sources & References

How Claude remembers your project, Claude Code docs — https://code.claude.com/docs/en/memory

Voice narration is AI-generated.

Could some jobs actually need protection from AI? Bill Gates has proposed “Human Reserved” jobs and taxes on AI and robots to slow workforce disruption. This episode examines his ideas alongside current research from the ILO, IMF, OECD, and World Economic Forum, and asks where AI should assist humans, replace tasks, or leave certain responsibilities to people. Voice narration is AI-generated.

REFERENCES

Bill Gates — The choices we make about AI now are critical

https://www.gatesnotes.com/a-turbulent-ai-era-and-critical-choices-to-make

International Labour Organization — Generative AI and Jobs: A 2025 update

https://www.ilo.org/publications/generative-ai-and-jobs-2025-update

IMF — AI Will Transform the Global Economy. Let’s Make Sure It Benefits Humanity

https://www.imf.org/en/blogs/articles/2024/01/14/ai-will-transform-the-global-economy-lets-make-sure-it-benefits-humanity

OECD — Using AI in the workplace

https://www.oecd.org/en/publications/using-ai-in-the-workplace_73d417f9-en.html

World Economic Forum — Future of Jobs Report 2025

https://www.weforum.org/stories/2025/01/future-of-jobs-report-2025-jobs-of-the-future-and-the-skills-you-need/

Software development is changing quickly, but the useful response is not to chase every new AI product. The better question is which capabilities will make a software engineer more valuable in an AI-assisted development environment.

The episode focuses on eight areas.

1. AI coding tools. Modern coding agents such as Codex can inspect repositories, plan changes, edit files, run tests, debug problems, and prepare work for review. The important skill is moving beyond autocomplete: developers need to direct, supervise, review, and verify agent-generated work. OpenAI describes Codex as capable of taking engineering work from issues through tested, review-ready code.

2. AI architecture. Engineers do not need to train foundation models to work effectively with AI. They should understand LLMs, context, retrieval and RAG, embeddings, tool calling, agent loops, memory, skills, MCP, permissions, guardrails, and tracing. The goal is being able to explain where an AI application's information comes from, what actions the model can take, and what happens when the system fails.

3. Context engineering. An AI model can perform poorly when it receives the wrong information. Coding-agent context can include the repository, instructions, architecture documentation, requirements, tests, tools, skills, and previous decisions. Martin Fowler's 2026 work on context engineering describes the growing importance of deliberately shaping this environment. Good code structure, documentation, tests, and clear conventions can therefore help both humans and agents.

4. Computer science fundamentals. AI-generated code does not eliminate the need to understand algorithms, data structures, databases, networking, operating systems, concurrency, distributed systems, APIs, security, Git, and testing. The more implementation AI can produce, the more important it becomes to understand the consequences of the implementation.

5. Verification and debugging. When code generation becomes cheaper, the ability to determine whether software is correct becomes more valuable. Engineers need testing, code review, debugging, observability, performance analysis, security testing, and regression testing. AI-generated code can look polished while still making incorrect assumptions or introducing subtle problems.

6. Architecture and systems thinking. Engineers should understand APIs, databases, queues, caches, events, services, cloud infrastructure, identity, observability, data pipelines, and security boundaries. AI systems add components such as model gateways, retrieval systems, vector stores, agent harnesses, memory, tools, and orchestration. The valuable skill is turning a vague requirement into a reliable system and understanding its failure modes.

7. AI security.

8. Requirements and specification.

REFERENCES

OpenAI — Codex for Software Engineering Teams

https://openai.com/business/solutions/engineering/

OpenAI — Codex

https://openai.com/codex/

OpenAI — Unrolling the Codex Agent Loop

https://openai.com/index/unrolling-the-codex-agent-loop/

OpenAI — Harness Engineering: Leveraging Codex in an Agent-First World

https://openai.com/index/harness-engineering/

OpenAI — Running Codex Safely at OpenAI

https://openai.com/index/running-codex-safely/

OpenAI — How Agents Are Transforming Work

https://openai.com/index/how-agents-are-transforming-work/

Martin Fowler / Thoughtworks — Context Engineering for Coding Agents

https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html

Anthropic — Engineering and Coding Agent Research

https://www.anthropic.com/engineering

Authoring Agent Skills: A Software-Engineering Approach

https://arxiv.org/abs/2607.25032

Engineering Reliable Coding Agents: Evaluating and Operating the System Around the Model

https://arxiv.org/abs/2608.13867

Self-Evolving Coding Agents

https://arxiv.org/abs/2608.03392

Voice narration is AI-generated.

As AI agents begin working with other agents, a new security question appears: if one agent delegates work to another, when should it trust the result?

The episode separates three concepts that are often confused. Authentication asks, "Who are you?" Authorization asks, "What are you allowed to do?" Trust asks whether the receiving agent should rely on another agent for a particular task or result.

The Agent2Agent, or A2A, protocol is one of the major efforts addressing agent-to-agent communication. A2A 1.0 provides a standardized way for independent agents to discover capabilities and collaborate without exposing their internal memory or tools. An Agent Card describes an agent's identity, endpoint, capabilities, skills, and authentication requirements.

An Agent Card, however, is a description, not proof of trust. A2A uses established web security mechanisms including HTTPS, OAuth, API keys, OpenID Connect, and mutual TLS. These mechanisms can establish and verify identity and support authorization, while authorization policies can limit access based on identity, requested skills, actions, scopes, and data policies.

The episode then makes an important distinction between trusting an agent and trusting its output. An agent can be authenticated and authorized to perform a task while still producing an incorrect conclusion. Important results may therefore need evidence, citations, independent verification, or other checks appropriate to the risk.

Delegation creates another challenge. If Agent A asks Agent B to perform work, and Agent B asks Agent C to retrieve data, the permissions given to Agent A should not automatically give every downstream agent unlimited access. This is why least-privilege authorization and controls around delegated actions are important.

Provenance is another part of trustworthy multi-agent systems. When several agents contribute to a final result, the system should be able to identify where important information came from, which agent produced it, and how it moved through the workflow. This becomes especially important when agents operate across organizational boundaries.

The episode also notes that agent identity is still an emerging area. Current proposals and Internet-Drafts are exploring stronger, verifiable identities and provenance for agents and delegation chains. These are developing standards, not settled industry requirements.

The practical approach is to evaluate trust according to the situation. Start with identity, verify authentication, check authorization, consider the sensitivity of the data and action, and verify important results. High-impact actions should receive stronger controls than low-risk information requests.

The central idea is that an AI agent should not trust another agent simply because the two can communicate. Trust is built from identity, authentication, authorization, provenance, evidence, and an understanding of the consequences if the other agent is wrong.

REFERENCES

A2A Protocol — A2A 1.0 Specification

https://a2a-protocol.org/latest/specification/

A2A Protocol — Security

https://a2a-protocol.org/latest/topics/key-concepts/

Google — A2A Protocol

https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

OpenAI — Introducing the Agents SDK

https://openai.com/index/new-tools-for-building-agents/

OpenAI — The next evolution of the Agents SDK

https://openai.com/index/the-next-evolution-of-the-agents-sdk/

IETF — Agent Identity and Authentication Internet-Draft

https://datatracker.ietf.org/doc/draft-rosenberg-agent-auth/

Voice narration is AI-generated.

How can an AI agent remember that you prefer short emails, know which project you're working on, or pick up a task you started yesterday? An agent can create this experience by storing useful information outside the model's immediate context and retrieving the right pieces when they become relevant.

The episode explains several layers of memory. Working context contains the current conversation, instructions, tool results, and information needed for the task. Longer-term memory can include procedural information about how the agent should behave, semantic facts such as preferences or project details, and episodic information about previous events. These are useful mental models rather than a universal standard, since different systems implement memory differently.

The episode then connects memory to retrieval-augmented generation, or RAG. RAG retrieves external information and places relevant material into the model's context. Memory can use the same general retrieval pattern to bring information from the past into a current task. Retrieval does not have to mean vector search: an agent can also use SQL, documents, APIs, files, or other sources.

Context engineering is important because the model's active context is limited. Anthropic's current guidance emphasizes selecting useful information and using just-in-time retrieval rather than loading an entire knowledge base into every request.

Memory also has to change over time. If a user once preferred morning meetings and later says afternoons work better, the system needs to update or supersede the older preference. A memory system therefore needs rules for what to keep, what to retrieve, how to handle conflicting information, and when information should be removed.

There is also a privacy dimension. If an agent stores information about a person, users need controls over what is remembered, what can be retrieved, and what can be deleted. Memory is therefore part of the agent's data architecture and permissions model.

The key idea is that an AI agent does not remember people the way a person does. It stores information outside the model's immediate context, retrieves useful pieces when needed, and places them into the context used for the next decision. Memory, retrieval, and context management work together to create the experience of an agent that knows you over time.

REFERENCES

Anthropic — Effective context engineering for AI agents

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Anthropic — Effective harnesses for long-running agents

https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

OpenAI — Memory and new agent capabilities

https://openai.com/index/memory-and-new-agent-capabilities/

OpenAI — New tools for building agents

https://openai.com/index/new-tools-for-building-agents/

Voice narration is AI-generated.

How does an AI agent go from a language model that generates text to a system that can research, use software, change files, and work through a task? Episode 30 explains the core architecture behind modern AI agents, focusing on the components surrounding the model rather than benchmark scores.
The episode starts with the LLM and the harness. The model provides the language and reasoning capability, while the harness supplies instructions, context, memory, tools, state, permissions, and execution behavior. OpenAI's current Agents SDK includes orchestration, tools, guardrails, and tracing, while its newer agent infrastructure supports controlled file and command execution. Anthropic's work on long-running agents similarly emphasizes context management and durable artifacts for work that spans multiple sessions.
Memory is then separated from the model's immediate context. The episode explains working context alongside longer-lived procedural, semantic, and episodic information, while noting that implementations vary. This leads into retrieval-augmented generation, or RAG, and the broader idea of context engineering. RAG can use embeddings and vector search, but an agent can also retrieve information through SQL, document search, APIs, files, or web tools. The episode emphasizes just-in-time retrieval because sending too much information into a context window can make useful information harder to use.
Context engineering ties these pieces together. The challenge is not simply putting more information into the model. It is selecting useful information at the right time and in a form the model can use. That includes deciding which memories to retrieve, which tool results to keep, which instructions to prioritize, and what older information can be compacted or discarded.
Tracing provides visibility into the run. A trace can record model calls, retrieval, tool calls, inputs and outputs, timing, token usage, errors, and other metadata. Langfuse documents traces as structured records containing observations such as generations, retrieval operations, and tool calls, while OpenAI's Agents SDK includes tracing and observability for agent workflow execution.
The final concept is LLM Ops: the ongoing engineering loop around the running system. Teams inspect traces, identify failures or inefficiencies, adjust prompts, tools, retrieval, models, memory, or guardrails, and run the system again. The episode closes with a simple architecture: LLM, harness, context and memory, retrieval, tools, loop, guardrails, tracing, and operational improvement.
References
OpenAI — New tools for building agentshttps://openai.com/index/new-tools-for-building-agents/
OpenAI — The next evolution of the Agents SDKhttps://openai.com/index/the-next-evolution-of-the-agents-sdk/
Anthropic — Building Effective AI Agentshttps://resources.anthropic.com/building-effective-ai-agents
Anthropic — Effective context engineering for AI agentshttps://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Anthropic — Effective harnesses for long-running agentshttps://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Anthropic — Writing effective tools for AI agentshttps://www.anthropic.com/engineering/writing-tools-for-agents
Langfuse — Core Concepts: Traces and Observationshttps://langfuse.com/docs/observability/data-model
Langfuse — Tracinghttps://langfuse.com/academy/tracing
Voice narration is AI-generated.