Changelog_
Agno now checkpoints runs at the tool-batch level and exposes a unified /continue endpoint that handles both regenerating a run and forking it, along with support for forking sessions. Together they let you branch off a run at a known-good point rather than starting over, which is the kind of control that makes long, expensive agent runs practical to operate.
See the checkpointing cookbooks for examples.
A new StudioTool toolkit lets an agent dynamically compose other Agno primitives, assembling agents, teams, and workflows at runtime rather than wiring them all up ahead of time. It turns agent orchestration into something an agent itself can drive.
Learn more in the StudioTools docs.
GeminiInteractions now imports lazily, so pulling in Gemini no longer forces google-genai 2.0 on your environment. That frees up the dependency range, and Agno now supports google-genai through 2.9, so Gemini coexists with the rest of your stack instead of dictating its version.
View the Gemini Interactions docs for more.
The PII guardrail's custom_patterns now accepts raw regex strings and compiles them for you, so you can add a pattern inline instead of pre-compiling it yourself. Extending PII detection with your own rules takes one less step.
View the PII Detection Guardrail docs for more.
ClickHouse and Pinecone vector DBs now report their supported search types through get_supported_search_types(), matching the other vector stores. You can check what a backend supports programmatically rather than discovering it by trial and error.
View the ClickHouse docs and the Pinecone docs for more.
Rebuilding a DB-stored agent or team now reuses the live model instance from the registry instead of reconstructing it from scratch. Connection parameters like azure_endpoint and base_url, along with credentials, now survive that round trip rather than being dropped to None. Agents backed by Azure or any custom-endpoint provider keep working after a reload instead of losing the settings they need to connect.
Loading agents and teams from the database now isolates each component, so a single bad component gets skipped instead of dropping the whole set. Along with it, the model provider now round-trips correctly through deserialization, TuningEngines is registered, and the model catalog is deduplicated by model class. Together these mean a malformed or unrecognized piece no longer takes your other agents down with it, and the catalog stays clean.
Learn more about Agno Components in the docs.
The registry now deduplicates toolkits by their type, name, and function set, so a toolkit that gets re-instantiated collapses onto the existing entry instead of adding a duplicate. Your registry reflects the tools you actually have rather than accumulating repeats as components are rebuilt.
View the Registry docs for more.
The AgentOS MCP server at /mcp is now a real extension point, configured through a single MCPServerConfig object rather than custom middleware. You can register your own tools as plain callables or Agno @tool/Function objects, and scope the built-ins by turning them off with enable_builtin_tools=False or filtering with include_tags/exclude_tags. A tool can receive the authenticated caller's identity by declaring user_id, which AgentOS fills from the JWT subject while hiding it from the client-facing schema, so a tool acts on behalf of the real caller without exposing that field. You can gate calls with a one-line authorize function and switch on built-in DNS-rebinding protection through allowed_hosts/allowed_origins, all expressed as data. It stays fully backward compatible: with no mcp_config, the built-in tools register exactly as before.
See the AgentOS MCP docs for setup.
AgentOS now exposes create, read, update, and delete endpoints for learnings, giving you direct control over what an agent has learned instead of treating that store as write-only. You can list and filter records, edit a specific one, or delete a user's learnings outright, so correcting or clearing what an agent knows no longer means reaching into the database by hand. The /learnings endpoints turn on automatically once you enable learning on an agent and serve it through AgentOS.
Learn more about managing learnings in the docs.
Gemini no longer does a per-response cleanup that could race when multiple responses were in flight at once. Removing it clears a source of intermittent failures under concurrent usage, so agents hitting Gemini from many requests in parallel behave reliably instead of tripping over shared state.
View the Gemini docs for more.
For providers that use json_object structured output, Agno now passes the JSON formatting instructions into the follow-up prompt as well, not just the initial one. Follow-up turns keep returning well-formed JSON instead of drifting once the original instruction falls out of view.
MultiMCP now handles connection failures cleanly (v2.6.13), so a single server that fails to connect no longer disrupts the others. The remaining servers stay available instead of the whole setup going down with one bad connection.
Content hashing now folds metadata into the content hash (v2.6.13), so upsert=False inserts of the same document no longer collapse into one. Documents that share content but differ in metadata are stored as separate records the way you'd expect.
A ready-made Slack app manifest now ships for the AgentOS Slack interface (v2.6.13), so you can create the Slack app from a known-good configuration instead of assembling scopes and settings by hand. Slack lets you create an app directly from a manifest, so this drops straight into that flow.
See the Slack interface docs for setup, including the cookbook guide.
Paused workflows now surface approval requests and take responses over a live socket connection (v2.6.13), so a reviewer can approve or reject mid-workflow in real time rather than polling for pending steps. Human-in-the-loop steps resolve as they happen instead of stalling the run.
See the HITL docs for the approval patterns.
The registry gained knowledge and managers support (v2.6.10), and the AgentOS registry now auto-populates from the agents, teams, and workflows you've defined (v2.6.13). That removes a manual registration step and keeps the registry in sync by default.
See the Registry docs for more.
Context providers now stream their sub-agent events through to the parent run (v2.6.10, refined in v2.6.13), so a provider that runs its own sub-agent surfaces that work as it happens instead of going quiet until the final result. You get visibility into the intermediate steps, not just the final answer.
See the v2.6.10 release notes for more on this update and learn more about context providers in the docs.
A new Latitude observability example sends traces via OpenInference, giving you a ready reference for piping agent traces into Latitude rather than figuring out the integration yourself.
Check it out here.
A new worked WorkOS RBAC example gives you a concrete starting point for wiring role-based access control into an AgentOS deployment, instead of assembling the pattern from scratch.
Learn more in the RBAC WorkOS BYOT (Bring Your Own Token) docs.
Tuning Engines joins the lineup as a new model provider, extending the set of models you can run agents on without leaving Agno.
See the Tuning Engines docs to learn more.
The AG-UI integration now emits state events, so a front-end built on AG-UI can follow an agent's state as it changes and react in real time rather than waiting for the run to finish. Your UI reflects what the agent is doing moment to moment instead of polling or guessing.
SSee the Agent-User Interaction Protocol docs for more.
FileGenerationTools adds two output formats: DOCX (v2.6.10) and HTML (v2.6.12), the latter shipping with an example app. An agent can now return a finished .docx or a standalone web page instead of raw text for someone else to format, the same way it already generates CSV, JSON, and TXT. Document and report workflows deliver the file your users actually open.
See the File Generation docs for the full format list.
A new Manifest adds per-entity UI metadata to AgentOS, so every agent, team, and workflow carries its own presentation details rather than sharing one generic look. Each entity can define how it shows up in the interface, which makes a multi-entity AgentOS easier to navigate and tell apart at a glance.
The Parallel integration now reaches beyond web search. v2.6.11 added tools for Parallel's Task API and Monitor API, so an agent can kick off task executions and track their progress rather than only running searches. Later releases kept the integration current: v2.6.16 and v2.6.17 migrated the Parallel backend and tools onto the GA parallel-web 1.0 API, so you build against the stable interface instead of a preview.
See the cookbooks for reference examples and the v2.6.11 release notes for the original addition.
Agno adds first-party integrations for four more providers, widening the set of models you can run agents on without leaving the framework. Inception Labs, Xiaomi's MiMo, and MiniMax (M2.7) join as direct model providers, and Cloudflare AI Gateway lands as a provider too, so you can route requests through your gateway and pick up its caching and observability instead of calling each model endpoint directly.
View the docs for more:
A new YouTools toolkit wires up the You.com Search API, so an agent can run web searches through You.com with no custom client to build. Drop the toolkit onto an agent and it gains search the same way it picks up any other Agno toolkit.
See the YouTools docs for setup.
Agno now supports DOCX file generation, so an agent can produce a finished .docx as output rather than handing back raw text for someone to format. Document-producing workflows can deliver the file your users actually want.
Context providers can now stream the events from their sub-agents, so a provider that runs its own agent surfaces that work as it happens instead of going quiet until the final result. You get visibility into intermediate steps for live progress and debugging.
The registry now supports knowledge and managers alongside the components it already tracks, so you can register and reuse those pieces through the same mechanism rather than wiring them up by hand each time.
See Registry docs for more.
Agents, teams, and workflows now persist cancelled runs properly, so a run that gets cancelled is recorded in the database instead of vanishing. Your run history and downstream tooling see the cancellation rather than a gap.
The RunCompleted event now carries a files field, so anything listening for run completion can grab the files a run produced directly off the event instead of fetching them separately.
The model string parser now recognizes the google-interactions provider, so you can select GeminiInteractions through a model string rather than importing and constructing the class yourself. It lines up with the shorthand the other providers already support.
Updated DeepSeek V4's thinking mode and default settings so agents on DeepSeek run against current, sensible defaults out of the box.
Post-hooks and observability integrations can now read the complete resolved approval record, including resolved_by and resolved_at, through run_response.metadata["approval"]. Earlier only status and resolution_data were exposed, so audit and notification logic had no way to see who resolved a run or when. Keeping the record in metadata means it reads the same way across RunOutput, TeamRunOutput, and the future WorkflowRunOutput.
PgVector(prefix_match=True) used to be a silent no-op: it appended a * and then routed through websearch_to_tsquery, which ignores wildcards. It now routes through to_tsquery with proper tokenization, so a partial query like "ani" full-text matches "animal" the way the docs always described. A new cookbook walks through the help-center typeahead use case it unlocks.
On the agent path for Antigravity and Deep Research, the autonomous loop runs its tools inside Google's server-managed sandbox. Agno used to surface those steps as local tool calls, which triggered Function <name> not found errors and follow-up 400 invalid_request failures. Those server-side steps are now skipped on the agent path, so managed agents run cleanly. The model path with your own declared tools is unchanged.
Claude on Anthropic, AWS, and VertexAI used to silently drop an explicit 0 for temperature, top_p, or top_k, since a bare truthiness check treated 0.0 as unset and fell back to the API default near 1.0. Agno now checks is not None, so setting any of these to 0 produces the deterministic output you asked for instead of quietly reverting to a random one.
Managed Deep Research and Antigravity
You can now run Google's two most capable managed agents, autonomous research and a code-running sandbox, without leaving the Gemini setup you already have.
GeminiInteractions reaches both of them through the same model class. You switch one on by setting the managed agent in place of a model ID, so there's no new client and no separate integration to wire up.
Agent 1: hand off the research, get back a cited report. Deep Research plans the task, browses the web, and returns a researched report with citations. It runs in the background, with streaming you can reconnect and resume after a dropped connection, so a long job survives a flaky network instead of starting over.
from agno.agent import Agent
from agno.models.google import GeminiInteractions
research = Agent(
model=GeminiInteractions(id="deep-research-preview-04-2026"),
)
research.print_response("Research solid-state battery commercialization.")
Agent 2: hand off the work, get back the artifacts. Antigravity is a general-purpose agent that plans, runs code, and produces artifacts inside a managed Linux sandbox, so it does the work rather than just describing it.
sandbox = Agent(
model=GeminiInteractions(id="antigravity-preview-05-2026"),
)
sandbox.print_response("Summarize the top 5 Hacker News stories as Markdown.")
Same model class, same interface you already use for Gemini. Swap the ID for a managed agent and you're running.
Managed-agent setup, including the config knobs for each, is in the Agno docs: https://docs.agno.com/models/providers/native/google/gemini-interactions
You can now give your agents a full code-running, web-browsing, file-editing sandbox without building or operating any of it.
Agno ships first-party support for Google's Antigravity agents in two shapes, so you get that power on your existing stack. Which one you pick comes down to a single question: Do you want Antigravity to be the agent, or to work for one?
Shape 1: run it as a full agent, on the surface you already operate.
AntigravityAgent serves straight through AgentOS, so a Google-managed sandbox agent gets native sessions, streaming, and UI without a separate stack to stand up or maintain.
from agno.agents.antigravity import AntigravityAgent
from agno.db.sqlite import SqliteDb
from agno.os import AgentOS
agent = AntigravityAgent(name="Antigravity")
agent_os = AgentOS(
agents=[agent],
db=SqliteDb(db_file="tmp/agentos.db"),
)
app = agent_os.get_app()
if __name__ == "__main__":
agent_os.serve(app="antigravity_agent:app", reload=True)
Add a db and you get persistent workspaces for free. Each interaction provisions a sandbox and returns an environment ID, and AgentOS stores it so later turns in the same session land on the same sandbox. Files, installed packages, and state carry over, instead of every turn starting from scratch.
Shape 2: keep your agent, give it sandbox superpowers.
AntigravityTools lets any existing Agno agent delegate sandboxed work to Antigravity without being rebuilt as one. Your agent keeps its own model and offloads only the part that needs a sandbox.
from agno.agent import Agent
from agno.models.google import Gemini
from agno.tools.antigravity import AntigravityTools
agent = Agent(
name="Research Assistant",
model=Gemini(id="gemini-2.5-pro"),
tools=[AntigravityTools()],
markdown=True,
instructions=[
"When a task benefits from a sandboxed Linux environment with web search "
"and code execution, delegate it via run_antigravity_task.",
"Otherwise answer directly.",
],
)
agent.print_response(
"Use the sandbox to find the latest stable Python release and summarize what changed."
)
Now it can delegate code, search, and file work to a managed sandbox.
Same underlying API, two ways to get the benefit: one for when Antigravity is the worker, one for when it is the helper.
Docs for the agent: https://docs.agno.com/agent-os/multi-framework/antigravity
Docs for the toolkit: https://docs.agno.com/tools/toolkits/others/antigravity
ParallelMCPBackend now sends a User-Agent: agno/<version> header on every request, so Parallel can attribute the traffic your agents generate. Behavior is unchanged; the requests just carry clear provenance now.
EvalsDomainConfig drops its unused available_models field, leaving the top-level AgentOSConfig.available_models as the only supported source for the model dropdown in the Evals UI. With one place to set the list, the two can no longer drift out of sync.
Updated the Chonkie dependency pin as a follow-up to #7869, so installs resolve to the version Agno expects.
Renamed gemini-3-flash-preview to gemini-3.5-flash across the Gemini Interactions cookbooks, so copied examples run against the current model ID instead of the preview name.
A new GeminiInteractions model class builds on Google's stateful Interactions API, so agents can talk to the interactions endpoint directly instead of Gemini's generateContent. Rather than resending the full conversation on every turn, it stores prior turns server-side and references them by ID, so only the new message goes over the wire. That pulls down token cost and latency through implicit caching, and it opens the door to background execution for long-running work like Deep Research. The Agent class tracks the interaction ID for you, so multi-turn conversations just work.
Action required: Install google-genai>=2.0 to use it. The Interactions API is experimental and may change in future versions.
See the Gemini Interactions docs for the full capability set.
AgentOS now offers an opt-in per-user data isolation layer for authenticated endpoints, so one deployment keeps each user's data separated rather than pooling it together. Teams running multi-tenant setups can serve many users from a single AgentOS without standing up separate instances just to keep data apart. It stays off until you enable it, so existing deployments carry on unchanged.
See the RBAC docs for how it fits alongside scopes and authorization. View the Per-User Data Isolation docs for more on authorization.
URL-fetching knowledge readers now take an allowed_hosts parameter, so a reader pulls only from hosts you trust and rejects everything else. This closes the same SSRF and data-exfiltration surface during knowledge ingestion that any link-following fetcher opens in production.
See cookbook for more reference.
Qdrant's async_insert no longer calls the sparse encoder twice. Hybrid inserts now encode once, cutting wasted compute on every write to a Qdrant collection.
A child agent's spans no longer overwrite the parent trace's session_id, agent_id, or team_id when both share a trace_id. The fix shows up most clearly when a Team uses a background post-hook such as @hook(run_in_background=True), where the parent trace now holds onto its own identifiers instead of inheriting the child's.
The workflow HITL continue path now calls the async acleanup_run when it runs in an async context, rather than the synchronous version. Resuming a paused workflow behaves correctly under async execution instead of mismatching the running event loop.
Reviewers no longer have to chase pending approvals one at a time. The Slack interface now supports multi-row approvals with all pause types covered, so a reviewer can resolve several pending approvals in one place without leaving the channel. Confirmations, user-input prompts, structured feedback, and external-execution steps all surface as interactive TaskCards, and each rejection still collects a reason where one applies and passes it back to the agent so it can adjust.
Wiring it up is mostly one decorator and a db (paused runs persist and resume by run_id):
from agno.agent import Agent
from agno.db.sqlite import SqliteDb
from agno.models.openai import OpenAIResponses
from agno.os import AgentOS
from agno.os.interfaces.slack import Slack
from agno.tools import tool
@tool(requires_confirmation=True)
def deploy_service(name: str) -> str:
"""Deploy a service. The run pauses for approval before this runs."""
return f"Deployed {name}."
# A paused run persists to the database and resumes by run_id once the
# reviewer acts, so the Slack interface needs a db.
db = SqliteDb(db_file="tmp/approvals.db", session_table="agent_sessions")
agent = Agent(
name="Ops Agent",
id="ops-agent",
model=OpenAIResponses(id="gpt-5.4"),
tools=[deploy_service],
db=db,
)
agent_os = AgentOS(
agents=[agent],
interfaces=[Slack(agent=agent, reply_to_mentions_only=True)],
)
app = agent_os.get_app()
if __name__ == "__main__":
agent_os.serve(app="approvals:app", port=7777)
See the Slack HITL docs for the full set of pause types and cookbooks.
WikiContextProvider now supports a NotionDatabaseBackend source, so you can point an agent's wiki at a Notion database and have it query that content directly rather than maintaining a separate store. Teams already keeping knowledge in Notion can put it to work as agent context without copying it anywhere first.
Registering two tools under the same name on an agent or team used to fail quietly, with one definition shadowing the other and no signal as to why a tool misbehaved. Agno now warns you the moment a duplicate tool name is registered, so you spot the collision while you are wiring things up instead of debugging it in production.
aget_last_run_output no longer returns None when agent.id is auto-generated during arun(). You get the run output back whether or not you set an explicit agent ID, so code that reads the last result behaves consistently across configured and auto-generated agents.
The /continue endpoint now forwards dependencies and metadata through get_request_kwargs, so a resumed run sees the same context as the original call. Continued runs behave like the runs they pick up from instead of dropping configuration partway through.
LearningMachine now injects its context into the Team system prompt, not just the agent path. Teams get the same learned context that individual agents already received, so their behavior reflects it as expected.
Agno now supports multimodal inputs in the Gemini File Search API, so agents can index and semantically search across images alongside text rather than text alone. This is available with google-genai≥1.75.0; older versions remain text-only.
Action required: Bump google-genai to 1.75.0 or later to use image inputs with Gemini file search. Existing text-only setups keep working without changes.
See the cookbook example for an image-upload walkthrough.
Email and calendar are two of the most-requested grounding sources, and wiring them up usually means custom API clients and token plumbing. Two new context providers, GmailContextProvider and CalendarContextProvider, remove that work: both follow Agno's existing provider patterns and expose each source as natural-language query tools, so an agent reads mail and schedule context through the same consistent interface as every other source, with no bespoke retrieval layer to maintain. Alongside them, GDriveContextProvider now supports OAuth in addition to service-account auth, so an agent can connect to a user's own Drive without a service account.
Learn more about the Gmail provider and Calendar provider, or see the Context Providers overview.
Fetch tools that follow links are an SSRF and data-exfiltration risk in production. LLMsTxtTools now takes an allowed_hosts parameter that closes that surface: an agent only fetches from hosts you explicitly trust, and requests to anything outside the list are rejected, so agents can use llms.txt indexes without being able to reach arbitrary URLs.
File handling is powerful but not always wanted, so SlackContextProvider now puts it behind an enable_media_tools flag that defaults to False. Existing Slack integrations are unaffected until you opt in; when you do, download_file is added to the read tools and upload_file to the write tools, keeping file capabilities split cleanly along the existing read/write boundary.
The AgentOS scheduler now supports Mongo and AsyncMongo as backing stores, so teams already running on Mongo can schedule recurring runs of agents, teams, and workflows without standing up a separate database or external job scheduler. Cron-based background work stays on the infrastructure you already operate.
Conditional branches often wrap fragile work like external calls or tool execution, and until now a failure inside one would propagate unhandled and halt the run. The Condition workflow step now takes an on_error parameter that gives you explicit control over what happens when a sub-step fails, so a workflow can recover or continue instead of failing outright.
Agno introduces WikiContextProvider, a context provider built specifically for wiki and knowledge-base content. It supports filesystem and git backends, so wikis can be loaded straight from a directory or pulled from a git-versioned source, and it can ingest content from the web as well. Read/write flags give teams explicit control over whether an agent is allowed to add new pages or only consume existing ones.
Why it matters: Internal wikis are usually the highest-signal source of organizational knowledge, including runbooks, architecture decisions, and onboarding guides, and they live in inconsistent places, from a docs folder to a git repo to a public site. WikiContextProvider gives agents a single, consistent way to read that content without bespoke ingestion code, and the read/write controls keep human-curated knowledge bases from being modified by accident. For research, support, and engineering agents, this collapses what used to be a custom integration into one configuration step.
Learn more:
- Context engineering docs
- Cookbooks:
- https://github.com/agno-agi/agno/blob/main/cookbook/12_context/14_wiki_filesystem.py
- https://github.com/agno-agi/agno/blob/main/cookbook/12_context/15_wiki_git.py
- https://github.com/agno-agi/agno/blob/main/cookbook/12_context/16_wiki_with_web.py
- https://github.com/agno-agi/agno/blob/main/cookbook/12_context/17_wiki_dual.py
A round of fixes makes Slack-backed agents more predictable in production. The interface now gracefully falls back to public channels when the groups:read scope is missing, rather than failing outright, so agents continue to operate under reduced OAuth permissions. Read-instruction overrides have been restored and briefing guidance has been tightened, giving teams more consistent agent behavior across read and write modes. Update operations are now exposed correctly in agent mode, with agent mode returning query-only results where appropriate.
Why it matters: Slack deployments often involve carefully scoped OAuth permissions, custom briefing instructions, and a mix of agent and assistant modes. Each of these fixes removes a sharp edge that previously required workarounds, so teams running Slack agents at scale get more reliable behavior without changing their configuration.
SlackContextProvider has been simplified to a single, self-documenting configuration surface. The for_bot_read(), for_assistant_search(), and for_write() factory methods have been removed in favor of explicit flags on the provider, and SlackTools construction is now inlined so the underlying tool exposes its own capabilities directly. A new opt-in enable_workspace_search parameter is also available for agents that need to search across the workspace.
Action required: If you previously instantiated SlackContextProvider through one of the factory methods, replace those calls with direct construction using the relevant flags. Code that already constructs the provider directly is unaffected.
Why it matters: Factory methods made it harder to see what an agent could actually do with Slack at a glance, and forced runtime mode-switching when configurations needed to combine read, search, and write. Explicit flags make capability composition obvious in the agent definition, simplify reasoning about least-privilege access, and remove a layer of indirection that was easy to misconfigure.
Check out the cookbook for more.
Agno introduces WorkspaceContextProvider, a context provider purpose-built for agents that operate inside a repository root. It's backed by the read-only Workspace toolkit rather than generic file tools, so reading a repository and acting on it stay cleanly separated by default. Exclusion patterns for noise like .context, .venvs, dependency caches, and build artifacts are centralized across FileTools and Workspace, and FilesystemContextProvider now accepts an exclude_patterns parameter for teams that want to opt out or customize the defaults explicitly.
Why it matters: Pointing an agent at a repository is one of the most common patterns in agentic software, and one of the most token-expensive when it pulls in lockfiles, virtualenvs, and build output. Out-of-the-box noise filtering reduces context size, cost, and latency without forcing teams to maintain their own ignore lists. The read-only backing also means the provider is safe to attach to research and analysis agents that should never modify the repo they're reading.
Learn more in the Context engineering docs or the Cookbook.
A new Workspace toolkit gives agents structured access to a configurable root directory, with operations grouped by capability and destructive actions gated by human-in-the-loop confirmation by default. Read, list, and search run freely. Write, edit, move, delete, and shell pause for explicit approval before they execute. The toolkit is scoped to the directory you pass at construction, bounding an agent's blast radius to the path you specify.
Filesystem and shell access unlock the most useful "agent-as-coworker" patterns, including code generation, document editing, and operational scripts that touch real systems. Shipping these capabilities behind HITL by default makes it safe to put an agent in front of real work and expand write privileges progressively as confidence grows. The confirmation policy is configurable per action, so teams can tighten or loosen oversight without rewriting the agent.
Here's a minimal example. Reads run silently; writes pause for approval:
from agno.agent import Agent
from agno.tools.workspace import Workspace
agent = Agent(
model=...,
tools=[Workspace("/path/to/workspace")],
)
run = agent.run("Read draft.md and fix the typo on the line about typos.")
# Reads execute immediately. The edit pauses for confirmation.
while run.is_paused:
for requirement in run.active_requirements:
if requirement.needs_confirmation:
# Inspect requirement.tool_execution, then confirm or reject.
requirement.confirm()
run = agent.continue_run(run_id=run.run_id, requirements=run.requirements)
In AgentOS, pauses surface as approval cards in the run timeline. In a plain script, you drive the confirmation loop yourself, as shown above.
See the full cookbook example for the complete pattern, including how to wire up an interactive prompt.
Agno has updated the default model id used by several model providers to newer, actively supported versions. Agents that don't pin a specific model will now run on more current models, helping teams avoid upcoming provider deprecations, get more consistent performance, and in many cases lower inference cost.
Action required: If your application depends on specific model behavior, pin the version explicitly on the model class rather than relying on the default. For example, prefer OpenAIResponses(id="...") or Claude(id="...") over leaving id unset, so future default updates don't change your agent's behavior unexpectedly.
Why it matters: Provider model lifecycles move on the provider's timeline, not yours. Tracking defaults to actively supported models keeps existing Agno applications running smoothly through deprecations and avoids the operational scramble of a forced migration when an older model retires.
Agno now supports Anthropic's multi-block prompt caching for Claude models, giving teams granular control over what gets cached and for how long. You can define multiple system prompt blocks, each with its own cache setting and TTL of either 5 minutes or 1 hour, and opt in to caching tool definitions so the tool prefix is reused across requests. Tool serialization is also deterministic across Anthropic, OpenAI, Gemini, and Bedrock, so request prefixes stay stable from run to run and cached tokens actually hit.
Why it matters: Production agents with long system prompts or large tool catalogs can see meaningful reductions in inference cost and time-to-first-token without changing application logic. Caching is opt-in and configured at the model level, so existing agents are unaffected until you turn it on.
See Cookbook for reference.
WebContextProvider now ships with a Parallel backend, giving agents access to high-quality web search and page fetch through Parallel's hosted research service. The backend exposes both web_search and web_fetch with compressed markdown output, runs keyless by default for fast experimentation, and supports Bearer authentication or OAuth for higher rate limits and production workloads. Default timeouts are tuned for fetching larger pages, so long-running research calls complete reliably out of the box.
Why it matters: Adding web context to an agent traditionally meant wiring up a search API, building a fetcher, and managing rate limits and timeouts. The Parallel backend collapses that work into a single configuration option, so teams can stand up a production-ready research pipeline in minutes and focus on agent behavior instead of infrastructure.
Learn more in our Parallel MCP agent docs.
The openai: model prefix now resolves to OpenAIResponses rather than the legacy Chat Completions surface. New agents written as Agent(model="openai:...") automatically route through OpenAI's Responses API, giving teams access to its richer feature set, including built-in tools and improved streaming behavior, without code changes.
Action required: If your application depends on Chat Completions semantics, switch to the new openai-chat: prefix, for example Agent(model="openai-chat:gpt-4.1"). No action is needed for teams that already instantiate OpenAIChat or OpenAIResponses directly.
Why it matters: Aligning the default with the Responses API moves new agents onto OpenAI's actively developed surface, reduces friction when adopting newer capabilities, and makes the most capable behavior the path of least resistance for everyone building on Agno.
AgentOS now runs agents built with the Claude Agent SDK, LangGraph, and DSPy alongside native Agno agents, all through a unified AgentProtocol interface. Teams can standardize on one runtime, control plane, and observability layer without rewriting agents that already exist in other frameworks.
This turns AgentOS into a framework-agnostic platform. Engineering organizations can adopt Agno incrementally, bringing existing agent investments under a single production environment for sessions, tracing, scheduling, and role-based access control. It also reduces lock-in for teams evaluating multiple agent frameworks in parallel.
Available in beta. Native Agno agents remain fully supported with no changes required.
Learn more about Multi-Framework Support in our docs.
The new agno.context API lets agents reach into filesystems, web sources, SQL databases, Slack, Google Drive, and MCP servers as natural-language tools. What used to require custom integrations, retrieval pipelines, or bespoke tool wrappers now works through one first-party interface.
Context providers turn live data sources into queryable context for any agent, without forcing teams to build and maintain their own retrieval layer. Agents stay grounded in the actual systems your organization already runs, and platform owners get a consistent integration surface to govern and observe.
This shortens time-to-value for retrieval-heavy use cases and removes a recurring source of glue code from production agent stacks.
Browse all built-in context providers in our docs.
AgentFactory, TeamFactory, and WorkflowFactory let you create agents, teams, and workflows dynamically at runtime instead of defining them statically at startup. Each request can spin up its own configuration, drawing on per-tenant settings, runtime context, or user-specific permissions.
For platform teams running shared infrastructure across customers, departments, or business units, this removes a structural limitation. You no longer need a separate process or deployment to isolate configurations between tenants. One AgentOS instance can serve many distinct contexts with appropriate boundaries.
The factory pattern also makes A/B testing, gradual rollouts, and per-environment customization straightforward, since the agent definition is decided when the request arrives rather than baked into the deployment.
Learn more about Dynamic Agents in our docs.
Human-in-the-loop is now available for Teams, with full support in the AgentOS chat interface and a dedicated API layer. Operators can review, intervene in, and steer team-level decisions the same way they already can with single agents.
Multi-agent teams often produce more consequential output than individual agents, since they coordinate across roles to complete higher-stakes tasks. Adding HITL at the team level closes a governance gap for organizations deploying teams in customer-facing or regulated workflows.
This gives platform owners a consistent oversight model across single agents and teams, so review processes, escalation paths, and compliance controls work the same way regardless of how an agent system is structured.
Learn more about HITL for Teams in our docs.
Teams now support approval flows through both the API and the AgentOS chat interface. Sensitive actions can be paused for explicit human sign-off before they execute, giving operators a clear control point for high-impact operations.
Approvals work the same way they already do for single agents, so teams managing both can apply consistent governance policies across them. Engineering and compliance leaders can require human authorization for actions like financial transactions, data writes, customer communications, or any step that needs accountability before it ships.
This makes multi-agent teams safer to deploy in production environments where every action needs an audit trail and a responsible decision-maker on record.
Learn more in the Approvals docs.
Background runs streamed over Server-Sent Events can now reconnect and resume after a disconnection or page refresh. Operators rejoin the run exactly where they left off, with full context preserved.
Long-running agents and teams are common in production, particularly for research, analysis, and multi-step automation. Until now, a transient network drop or browser refresh meant losing the run or restarting from the beginning. The new behavior eliminates that failure mode, making AgentOS more reliable for the workflows users actually run on it.
For operators monitoring live agent activity, this also means fewer interrupted sessions and less wasted compute spent regenerating progress that was already complete.
Learn more in the Background Execution docs.
The /sessions endpoint returns agent, team, and workflow sessions in a single response by default. This gives a complete view of session activity in one call, which is the most common use case for operations dashboards, audit views, and platform monitoring.
To filter for a specific session type, pass ?type=agent, ?type=team, or ?type=workflow as a query parameter.
This is a breaking change. Integrations that previously depended on the endpoint returning only one session type should add the corresponding type filter to preserve their existing behavior. Update any custom dashboards, monitoring scripts, or downstream services that consume this endpoint before upgrading to v2.6.0.
We fixed an issue where custom db table names set on components were being overwritten with defaults when those components were loaded back from configuration. Custom table names are now preserved correctly through the full save and load cycle.
GitHubConfig now accepts a repository override at the request level, allowing agents that work across multiple repositories to specify the target repo per call rather than being locked to a single repo at initialization time.
See cookbook
A new option lets you turn off file citations in Claude responses. This is useful when citations add noise to the output, for example in conversational flows, summarization tasks, or any context where surfacing source references per response is unwanted.
We fixed an issue where headers supplied by header_provider were not being applied during MCP session initialization, only during subsequent requests. Sessions now open with the correct headers from the start, preventing authentication and routing failures on first contact.
We fixed an issue where knowledge databases were not being built live during configuration API calls, causing agents to operate without their knowledge base until a separate build step was triggered. Knowledge databases are now constructed inline as part of the configuration flow.
We fixed an issue where events emitted by inner workflows could lose their identity or be misattributed when bubbling up through outer workflows. Events now carry a nested_depth field on agent and team events, and inner workflow event identity is preserved throughout, making it straightforward to trace exactly where in a nested pipeline any event originated.
We fixed an issue where a shared HTTP/2 client was being injected across all model providers, causing connection conflicts and transient failures under concurrent load. Each provider now maintains its own client, eliminating the source of these errors across all providers simultaneously.
We fixed an issue where cancellation of a client connection during streaming could surface as an unhandled error rather than being handled quietly. CancelledError is now caught explicitly in all router streaming generators, so cancelled connections close gracefully without producing noise in logs or error handlers.
We fixed an issue where JSON cleaning was stripping or corrupting code blocks embedded in string values before the parse was even attempted. The parser now tries a raw JSON parse first and only falls back to cleaning if that fails, preserving code blocks and other structured content in the output as intended.
We fixed an issue where parameters automatically injected by the framework, such as agent, team, and run_context, were appearing in user_input_schema, presenting users with fields they should never need to fill in. These parameters are now excluded, so only genuinely user facing fields appear in the schema.
We fixed an issue where the memory pipeline gate check did not account for extra_messages, causing memory summarization to be skipped in runs where additional context messages were provided alongside the main conversation. The gate now correctly evaluates the full message set, including extra_messages, before deciding whether to run the memory pipeline.
LLMsTxtTools and LLMsTxtReader add native support for the llms.txt standard — a Markdown-based file that websites publish at /llms.txt to provide LLMs with a concise, structured index of their documentation, free of navigation elements, JavaScript, and other noise that wastes context. Agents can now fetch, read, and work with llms.txt files directly, making it straightforward to build agents that are grounded in up-to-date third-party documentation without manual content pipelines.
Details:
LLMsTxtReaderingests anyllms.txtfile into a knowledge base for retrieval and RAGLLMsTxtToolslets agents fetch and queryllms.txtindexes directly as a tool call- Compatible with any site publishing the standard, including
https://docs.agno.com/llms.txt - No preprocessing required —
llms.txtfiles are already structured for LLM consumption
See cookbook for reference
SalesforceTools gives agents native access to Salesforce CRM data, making it straightforward to build agents that query records, surface pipeline information, triage support cases, or answer questions about account state — without custom API wrappers or manual data exports.
View the Salesforce docs to learn more.
We fixed an issue where knowledge_table was being read from agent.db instead of contents_db, causing knowledge lookups to fail or return incorrect results when the two databases were configured separately. Knowledge retrieval now correctly targets the intended storage backend.
We fixed two issues in the AG-UI interface: reasoning events are now correctly emitted as they occur so users can follow the model's thinking in real time, and input_content now stores the current user input rather than the full message history, ensuring the correct value is surfaced per turn.
We fixed an issue where workflow steps that included file path images were not being converted correctly, causing those images to be dropped or mishandled when passed between steps. File path images now flow through step conversion as intended.
We fixed handling of response.reasoning_summary_text.delta events in OpenAIResponses so that reasoning content is streamed incrementally as it is generated rather than being dropped or buffered. Users now see the model's reasoning surface in real time alongside the response.
We fixed TeamSession.from_dict() so it no longer mutates the input mapping it receives. Previously, loading a team session from a dictionary could silently modify the original data structure, causing hard-to-trace state issues in workflows that reused or inspected the source mapping after loading.
A new Azure AI Foundry Claude model provider gives teams a first-class way to run Claude models through Microsoft's Azure AI infrastructure, with the same configuration patterns used across other Agno model providers. This is particularly useful for organizations that require Azure-hosted deployments for compliance, data residency, or enterprise procurement reasons.
View the Azure AI Foundry Claude docs to learn more.
OpenAIResponses now supports background mode for the OpenAI Responses API, allowing long-running agent tasks to execute asynchronously without holding an open connection. This is useful for tasks that exceed typical request timeouts or that need to be dispatched and polled rather than streamed directly.
Workflows can now pause after a step completes and wait for a human to inspect the output before it flows to the next step. Configured via HumanReview(requires_output_review=True) on a Step, Router, or Loop, the run pauses with the full step output available in req.step_output. Reviewers can approve, reject with optional feedback to trigger a retry, or edit the output directly — giving teams a structured, auditable post-execution review gate at any point in a pipeline without custom orchestration code.
Details:
requires_output_reviewaccepts aboolor a callable predicate that receives theStepOutputat runtime — enabling conditional review (e.g., only pause for outputs over 200 characters, or outputs containing sensitive keywords)- Four reviewer actions:
confirm()to approve as-is,reject()to reject,reject(feedback="...")to pass correction instructions back to the agent on retry, andedit("new output")to accept with inline modifications on_rejectcontrols rejection behavior:skip,cancel,retry, orelse_branch; whenon_reject=OnReject.retry, the step re-executes with feedback injected into the agent's next messagemax_retries(default 3) caps the number of retry attempts before the step is treated as a final rejection- Supported on
Step,Router, andLoop(viarequires_iteration_reviewonHumanReviewfor per-iteration review in loops) - Flat parameter
requires_output_review=TrueonStepis still supported for backward compatibility
See the Output Review docs for more.
A Workflow can now be used directly as a step inside another workflow, enabling modular composition of reusable sub-pipelines. The inner workflow runs as a single step in the outer workflow, with its output chained to the next step via the standard StepInput/StepOutput interface. Complex orchestrations can be broken into smaller, independently testable units and assembled without duplicating logic — the same sub-workflow can be reused across multiple parent workflows.
Details:
- Pass a
Workflowinstance to aStepviaStep(name="...", workflow=inner_workflow), or use the shorthand auto-wrap by placing the workflow directly in thestepslist (uses the workflow'snameas the step name) - Inner workflows support the full set of primitives —
Condition,Loop,Router,Parallel, agents, and custom executors — mixed in any combination - Session state is deep-copied into the inner workflow before execution and merged back into the outer workflow after, keeping state consistent across levels
- Workflows can be nested multiple levels deep; streaming events bubble up with a
nested_depthfield so outer and inner events can be distinguished by depth,workflow_id, andworkflow_name - Enables modular workflow design: build reusable research, processing, or review sub-pipelines once and compose them into larger orchestrations
See the Nested Workflow docs to learn more.