Changelog_
New SmallestTools lets an agent generate speech with Smallest AI's Lightning models. Call text_to_speech to turn text into natural audio, or get_voices to see what's on offer. Nothing extra to install beyond agno, since the toolkit runs on Agno's own HTTP client, so it comes down to setting your SMALLEST_API_KEY and going.
from agno.agent import Agent
from agno.tools.smallest import SmallestTools
agent = Agent(
tools=[SmallestTools(voice_id="magnus", model="lightning_v3.1", target_directory="tmp")],
markdown=True,
)
response = agent.run("Generate a short welcome for a podcast on aviation history.")
# audio saves to tmp/ and is also on response.audio for a later step to use
There are two tiers to work with. lightning_v3.1 is the default and supports cloned voices, while lightning_v3.1_pro opens a premium voice pool with American, British, and Indian accents for broadcast-quality output. Set target_directory and the audio saves itself, or leave it off and pull the bytes off response.audio to pass along however you like. Output can come back as WAV, MP3, or a few telephony formats if you're feeding this into calls.
Check out Agno’s Smallest AI toolkit docs for more.
OpenSearch is now a supported vector database in Agno through agno.vectordb.opensearch. It handles vector, keyword, and hybrid search, in both sync and async variants, so you can back a knowledge base with OpenSearch whether you want semantic retrieval, plain lexical matching, or the two combined.
from agno.knowledge.knowledge import Knowledge
from agno.vectordb.opensearch import OpenSearch
from agno.vectordb.search import SearchType
vector_db = OpenSearch(
index_name="agno_docs",
search_type=SearchType.hybrid,
)
knowledge = Knowledge(vector_db=vector_db)
If OpenSearch already sits in your stack for search or log analytics, this lets you point an agent's knowledge at it instead of standing up a separate vector store to run alongside it. Install it with the agno[opensearch] extra, and the included run_opensearch.sh gets a local instance going for testing.
See the OpenSearch db cookbook for reference.
AgentOS adds a GET /metrics/refresh/status endpoint so clients can watch a background metrics refresh instead of waiting blind and timing out. It reports idle, running, completed, or failed along with started_at, finished_at, and any error, and the state updates even when a refresh finishes without writing new data, so a no-op still resolves cleanly rather than looking stuck. On the client it's available as AgentOSClient.get_metrics_refresh_status(), and for remote databases the status comes back from the remote AgentOS, so you get an accurate picture wherever your data lives.
View Agno’s Refresh Metrics docs to learn more.
New AgentOSTools gives an agent a read-only ops view of the AgentOS it runs on. Point it at your database and it can report on usage, latency, failures, schedules, evals, components, and pending approvals, then answer questions about any of it. Things like "which tool was slowest today," "how many runs failed this week," or "what's waiting on approval." You get answers grounded in real traces instead of clicking through a dashboard to assemble them yourself.
from agno.agent import Agent
from agno.db.sqlite import SqliteDb
from agno.tools.agentos import AgentOSTools
db = SqliteDb(db_file="tmp/platform.db")
ops_agent = Agent(
tools=[AgentOSTools(db=db)],
instructions="Answer ops questions about this AgentOS. Ground every number in a tool result.",
db=db,
)
ops_agent.print_response("Which tool was slowest today, and how many runs failed?")
The toolkit reads from the database, not from a live AgentOS handle. Your agents get built before the OS does, so wiring the tools to the db is what keeps this cleanly read-only: an ops agent can inspect the whole platform without changing a single agent, session, or config. It watches, it doesn't operate. It reports on whatever your deployment has traced, so with tracing on, the ops agent always has something real to pull from.
There's something usefully recursive here. The same framework you use to build agents now runs the agent that keeps an eye on them. Rather than a human refreshing a metrics page, you can put an agent on call that reads the traces, notices the slow tool or the jump in failures, and tells you in a sentence what's going on.
View the platform ops agent cookbook for more.
Traces now report latency and error stats grouped by agent, team, workflow, or endpoint, along with tool and model call stats, so you can see exactly where time goes and where things fail rather than reading traces one run at a time. It's available on PostgresDb and SqliteDb, giving you aggregate performance and reliability views straight from the database you already trace to.
View Agno’s Tracing docs for more.
View the platform ops agent cookbook for implementation.
Moonshot gains a use_thinking flag to turn thinking mode on or off, so you choose between deeper reasoning and faster, cheaper responses per use case. It also adds file and video input, letting an agent on Moonshot work over documents and video rather than text alone.
View the thinking mode cookbook with use_thinking
View the file input cookbook for file input
Moonshot now preserves reasoning_content from one turn to the next, so a model's prior reasoning carries forward instead of being dropped. Multi-turn conversations stay coherent, with each turn building on the thinking that came before it.
delete_by_metadata now binds metadata keys and values as query parameters rather than inlining them, so deletions run correctly and safely regardless of what the metadata contains. Special characters no longer break the query or open a value-injection path.
Agents are good at working with files, but the filesystem in most setups is a scratch directory that vanishes when the run ends. Fine for a one-shot task, useless for anything an agent is supposed to remember. Agno's new FileSystem is a durable text store an agent writes to and reads back across runs, so the decision it recorded and the checkpoint it saved are still there when it starts up again in a fresh process.
from agno.agent import Agent
from agno.db.sqlite import SqliteDb
from agno.fs import FileSystem
fs = FileSystem(SqliteDb(db_file="tmp/filesystem.db"))
agent = Agent(
tools=[fs.tools()],
instructions=["You keep durable working notes.", fs.instructions()],
)
agent.print_response("Record in notes/decisions.md: SQLite for dev, Postgres for prod.")
# run again in a new process and the note is still there to read back
You decide where the files actually live. Point it at SQLite for local development, Postgres for a deployed app running multiple workers, or local disk when you want to open the files in an editor yourself. The agent code doesn't change when you switch.
Namespaces are what make it safe to point at real users. Give it a templated namespace like "assistant/{user_id}" and each user's files are scoped to their own space, resolved from the run context at call time. The model can't reach into another namespace by passing a different path in a tool call, and if the user id is missing, the operation is blocked instead of running against the wrong space. You still enforce authorization at the backend, but the agent itself can't wander out of the namespace you put it in.
View the FileSystem docs to learn more.
TwelveLabsTools now supports Marengo embeddings. Marengo embeds text into the same latent space TwelveLabs uses for video, audio, and image, so a written query and a video clip come out as vectors you can compare directly. You describe what you're after, and the embedding lands right next to the moments that match it.
from agno.agent import Agent
from agno.tools.twelvelabs import TwelveLabsTools
agent = Agent(
tools=[TwelveLabsTools(enable_embed_text=True, enable_analyze_video=False)],
markdown=True,
)
agent.print_response("Embed 'a cat playing piano' so I can search my video index for it")
This is what you need to search a video library by meaning rather than metadata. Embed the query with Marengo, compare it against your indexed video embeddings, and get back the clips that actually show what you asked for instead of the ones that happen to name it in a title or transcript.
The toolkit's other half covers the single-video case. analyze_video uses the Pegasus model to answer natural-language questions about one clip, so an agent can both dig into a specific video and pull the right one out of a corpus of thousands.
View the TwelveLabs toolkit docs to learn more.
A new respond_to_other_apps flag lets a Slack agent respond to messages from other agents, not just people. Switch it on and your agents can coordinate and hand off inside a shared Slack channel, so multi-agent conversations play out where your team already works instead of behind a separate orchestration layer.
See the peer agents cookbook for more.
FileTools now exposes a directory parameter, so you can set where it reads and writes instead of relying on the default location. File operations land in the folder you specify, giving you cleaner control over where an agent's file work happens.
Learning stores add an extraction_tool_call_limit that bounds how many tool calls the extraction step can make. The extraction process stops at a sensible ceiling rather than spinning indefinitely, so a runaway loop can't rack up cost or stall a run.
stream_sub_agent_events is now supported across all context providers, not just a subset. Any provider that runs a sub-agent can surface its events as they happen, so you get consistent real-time visibility into intermediate work no matter which provider you reach for.
New in Agno: a straight path from evaluation to fine-tuning data, built from a few pieces that snap together. agno.scorer grades attempts, agno.environments runs an agent over a set of tasks in full isolation, and run_rollouts runs each task K times so you can see how often the agent actually succeeds instead of whether it managed it once.
Running a task once and watching it pass tells you almost nothing. Run it eight times and you get a real pass rate, which is what separates reliable behavior from a lucky draw. That number is pass@k, and you can now measure it directly instead of building a harness for it.
from agno.environments import Environment, Task, run_rollouts
env = Environment(
agent=agent,
tasks=[Task(input="...", scorer=my_scorer)],
)
results = run_rollouts(env, k=8) # every task, eight isolated attempts
print(results.pass_rate) # how often it actually worked
results.to_sft_jsonl("training.jsonl") # export the attempts that passed
From there it turns into a training tool. to_sft_jsonl takes the attempts that passed and writes them out as conversational SFT data, with a provenance sidecar so you can trace every example back to the exact run it came from. You point a strong agent at a task, let it try many times, keep what worked, and hand that straight to fine-tuning. It's rejection sampling, minus the pipeline you'd normally have to stand up around it.
The isolation is what makes that exported data worth trusting. Each attempt runs on a fresh db, session, and user, with no memory or learning writes bleeding between runs, so neither your pass rate nor your training set gets contaminated by state left over from an earlier attempt.
And if all you want is scoring inside your existing eval suite, Case.scorer drops any scorer into a Case and checks it exactly, with no extra model call.
See the environments cookbooks for reference.
FileGenerationTools now generates code files, extending the toolkit beyond documents and data formats. An agent can hand back a ready-to-run source file rather than pasting code into chat for someone to save off, so code-producing workflows deliver a real file you can open, run, or commit.
See the File Generation docs for the full format list.
Gmail tools now support pagination, with a max_results_per_request control over how many messages each request pulls. An agent can work through mailboxes and searches that run past a single page instead of stopping at the first batch, while you keep each request within the Gmail API's limits.
See the Gmail docs for usage.
A new AdanosTools toolkit gives agents multi-source stock sentiment and Reddit cryptocurrency sentiment from Adanos, drawing on signals across Reddit, X, financial news, and prediction markets. Research and analysis agents can fold real sentiment data into their reasoning rather than working from price alone. It's opt-in, so it's there when you want it and out of the way when you don't.
See the Adanos docs for setup.
New in Agno: SuperserveTools, which lets an agent write and run its own code inside a Superserve sandbox. The sandbox is a Firecracker microVM, and the part that matters is that it persists. Files the agent writes and packages it installs are still there on the next tool call, and the next run in the same session. That's the difference between running one-off snippets and actually doing long-running work, where the agent builds something up over many steps instead of starting from an empty box every time.
from agno.agent import Agent
from agno.models.openai import OpenAIResponses
from agno.tools.superserve import SuperserveTools
agent = Agent(
model=OpenAIResponses(id="gpt-5.5"),
tools=[SuperserveTools(timeout=600)],
markdown=True,
)
agent.print_response("Fetch the last 30 days of AAPL prices and plot the moving average.")
The secrets handling is worth knowing about. You bind a team secret and the sandbox only ever sees a proxy token. The real credential gets swapped in for outbound calls to the hosts you allow, so agent-written code can hit real APIs without your keys ever landing somewhere the model can read them. You can also switch runtimes with a template, or expose a port to get a public preview URL for whatever the agent builds.
Check out Agno’s Superserve toolkit docs to learn more.
New PlivoTools gives an agent a phone line. It can send SMS and place voice calls through Plivo, and look up a number before it does either.
from agno.agent import Agent
from agno.tools.plivo import PlivoTools
agent = Agent(tools=[PlivoTools()])
agent.print_response("Send an SMS saying 'Your order shipped' to +1234567890 from +1987654321", markdown=True)
The lookup is the quietly useful one. Before an agent fires off a message, it can check that the number is real and see the carrier and line type, which keeps you from wasting sends on dead or invalid numbers. It also reads back your call and message history, so an agent can follow up based on what already went out rather than starting blind. Set your PLIVO_AUTH_ID and PLIVO_AUTH_TOKEN and it's live.
Check out Agno’s PlivoTools docs to learn more.
We've added an observability integration with The Context Company, so you can trace Agno agent runs and understand how they behave in the wild. Setup is one line. Call instrument_agno() before you import Agno, and your runs start streaming over OpenTelemetry, capturing model calls, tool arguments and results, prompts, token usage, and latency.
from contextcompany.agno import instrument_agno
instrument_agno()
from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.tools.yfinance import YFinanceTools
agent = Agent(model=OpenAIChat(id="gpt-5.2"), tools=[YFinanceTools()])
agent.print_response("What is the current price of NVIDIA?")
Plain tracing shows you one run at a time. What The Context Company adds is analysis across all of them, surfacing recurring patterns and account-level insight and then linking back to the specific runs behind each one. So instead of scrolling traces hoping to spot a problem, you find out where your agents are consistently going wrong and can go straight to the evidence.
View Agno’s The Context Company docs to learn more.
agno create is now interactive, prompting you for a starter template and a project name instead of making you get the invocation exactly right up front. It adds four new starters for Azure, Helm, Modal, and Render, and seeds your .env automatically, so a new AgentOS project is ready to run with less manual setup.
View the Agno CLI docs for more.
Telegram tools gain pin_message, get_chat, get_file, and react_with_emoji, so agents can manage a chat more fully rather than just posting to it. New save_downloads and output_directory options write downloaded files straight to disk, making it easy to capture what comes through a chat.
Check out the Cookbook for more.
Tavily searches now accept domain, date range, topic, and country filters, so you can pin an agent's searches to exactly the sources, timeframe, and region that matter. You get tighter, more relevant search results instead of sifting through everything.
Learn more about Tavily search in Agno’s docs.
Oxylabs website scraping can now return full page content as Markdown, so an agent receives clean, structured text it can actually read and reason over rather than raw HTML. Downstream extraction and summarization work better with content that arrives ready to use.
View the Oxylabs Tools docs for more.
Router selectors and Condition evaluators now accept run_context, giving that logic access to the full run context when deciding which branch to take. This deprecates session_state in those spots, so you write routing and condition logic against one consistent, richer object going forward.
ValkeyDb brings Valkey to Agno as an in-memory database for agents, teams, and workflows. Your sessions and state live in memory, so reads and writes stay quick under load.
from agno.agent import Agent
from agno.db.valkey import ValkeyDb
db = ValkeyDb(host="localhost", port=6379)
agent = Agent(db=db)
Not every agent needs a full relational database sitting behind it just to hold session state. When latency matters more than durable long-term storage, backing your agents with Valkey keeps that path light and fast. Point an agent, a team, or a workflow at it and the storage layer stops being the slow part.
See the Valkey database docs for more.
Valkey also lands as a vector store, and it runs both vector and keyword search from the same backend. You can do semantic and lexical retrieval over one in-memory store.
from agno.knowledge.knowledge import Knowledge
from agno.vectordb.valkey import ValkeyDB
from agno.vectordb.search import SearchType
vector_db = ValkeyDB(
index_name="agno_docs",
host="localhost",
port=6379,
search_type=SearchType.vector, # or SearchType.keyword
)
knowledge = Knowledge(vector_db=vector_db)Standing up a vector store usually means running one more service alongside your cache. If Valkey is already in your stack for sessions, your knowledge base can live in the same instance, and because it's in memory the lookups stay quick as it grows.
See the Valkey vector store docs for setup.
New RedmineTools lets an agent work directly in Redmine, the open source project tracker. It can find and read issues, create and update them, leave comments, and log time against them.
from agno.knowledge.knowledge import Knowledge
from agno.vectordb.valkey import ValkeyDB
from agno.vectordb.search import SearchType
vector_db = ValkeyDB(
index_name="agno_docs",
host="localhost",
port=6379,
search_type=SearchType.vector, # or SearchType.keyword
)
knowledge = Knowledge(vector_db=vector_db)
If your team lives in Redmine, a lot of tracker upkeep is the kind of small, repetitive work nobody wants to context-switch for. An agent can file the issue, update the status, add the comment, and log the hours while you stay in the thing you were actually doing.
See the cookbook for a working example.
TokenLab joins as a new OpenAI-compatible model provider, so you can point agents at TokenLab using the interface you already know. Adding it takes no special wiring, since it speaks the OpenAI-compatible API.
See the cookbook for a working example.
Saving session context no longer makes an extra model call it didn't need. Cutting that redundant round trip trims latency and token cost on every save, so long-running sessions stay leaner without any change on your side.
AG-UI now extends its support for human-in-the-loop confirmation, input, and feedback, so more of your approval and input flows work natively through the interface. You can build richer interactive steps into an AG-UI front-end rather than working around the gaps.
View the AG-UI Human in the Loop docs for an example.
Memory and profile extraction from conversations is now more dependable, so agents pick up and retain the right details about a user more consistently. Personalization that leans on remembered context holds up better over the course of real conversations.
When an MCP server becomes unreachable, Agno now surfaces a clear error instead of a confusing failure. You can tell what actually went wrong and recover quickly rather than digging through an opaque stack trace.
MCP tools that respond with just structuredContent and no text block now work correctly. Agno reads the structured payload as intended, so tools following that response shape integrate without special handling.
Set AgentOS(mcp_auth=...) to put standards-based OAuth in front of your /mcp endpoint. Instead of relying only on tokens, you can gate MCP access through a proper OAuth flow, so connecting clients authenticate the way the rest of your stack expects and you get a familiar, auditable path for granting and revoking access.
See cookbooks the for a working setup:
AG-UI now supports client tool execution, so a tool can run in the frontend rather than only on the server. Your UI can handle actions that belong on the client, like reading local state or driving the interface, while the agent orchestrates the flow.
See the AG-UI docs for more.
agno connect gains the controls you need once you're wiring up more than one target. You can select multiple targets at once, tear a connection down with disconnect, and lean on restart hints when a client needs a nudge, while identity-named entries keep each connection clear about who it belongs to. Managing a fleet of coding-agent connections stays orderly instead of turning into guesswork.
View the Connect Your Clients docs for more on how to connect Claude Code, Claude Desktop, Codex, and Cursor to a running AgentOS over MCP with one command.
A2A scope mappings now live on the interface itself, with proper support for custom mount prefixes. Routes served under a non-default prefix get the scope checks they're supposed to, so authorization holds up no matter how you mount your A2A interface.
Learn more in the A2A docs.
Service accounts give AgentOS proper machine identities in the form of agno_pat_... personal access tokens. Run uvx agno connect and it mints a per-client token, writes the MCP config into your coding agent, and verifies the handshake, so you skip hand-editing JSON. The tokens are built for real security: stored as SHA-256 hashes, scoped per user, expiring after 90 days by default, revocable on demand, and enforced across every deployment mode, including /mcp and WebSockets.
See docs.
A new CLI ships as agnoctl on PyPI and runs as agno. agno connect discovers an AgentOS, mints per-client PATs, and writes MCP config for Claude Code, Claude Desktop, Cursor, Codex, and ChatGPT, then confirms each connection works. From there, agno tokens create/list/revoke manages your tokens, agno create scaffolds a new project from the agentos-<provider> templates for Docker, AWS, Fly, GCP, and Railway, and agno up/down/restart/status handles the lifecycle of a local deployment. You drive the whole platform from the terminal instead of stitching together manual steps.
View the Connect Your Clients docs for more on how to connect Claude Code, Claude Desktop, Codex, and Cursor to a running AgentOS over MCP with one command.
MCP Interface v2 exposes a clean eight-tool operator surface at /mcp: get_agentos_config, run_agent, run_team, run_workflow, continue_run, cancel_run, get_sessions, and get_session_runs. It trims run results by default so responses stay lean, sends progress notifications on long-running tools, and carries the full human-in-the-loop continue and cancel lifecycle. Your coding agent gets a predictable, purpose-built way to run and manage AgentOS rather than a sprawling tool list.
A new agno.eval layer gives you a proper suite runner built from Case and run_cases/arun_cases, plus an argparse CLI that supports team subjects and numeric judge scoring. SuiteResult.to_dict() gives you a stable JSON contract to wire straight into CI, so you can score agents and teams consistently and fail a build on regressions instead of eyeballing results.
A new GET /info endpoint reports the agno_version, whether MCP is enabled and at what path, and the auth_mode. External tooling like agnoctl can read what an AgentOS supports up front rather than probing blindly, which makes connecting and automating against it far more reliable.
View the Get OS Info docs for more.
A single AuthMiddleware on the parent app now covers REST, /mcp, and WebSocket transports, so auth no longer drifts from one transport to the next. JWTMiddleware stays as a backward-compatible alias, so existing setups keep working while every entry point enforces the same rules.
View the AgentOS AuthMiddleware docs to learn more.
check_route_scopes now runs identically across JWT, service-account, and MCP paths, and a data-driven get_resource_context_from_path replaces the old hardcoded substring matching. Access control behaves consistently no matter how a request arrives, so a scope you set means the same thing everywhere.
View the RBAC Custom Scope Mappings docs to learn more.
A2A and AGUI routes now enforce authorization alongside authentication, with scope mappings merged per interface at the mount prefix. Requests over these interfaces are checked against the scopes they actually need rather than being waved through once authenticated, closing a gap in multi-interface deployments.
MCP components now resolve through shared resolve_* helpers that make create_fresh deep copies instead of sharing singleton state, and a fresh session is minted per call whenever session_id is omitted. One request can no longer pick up another's history or state, so concurrent MCP traffic stays cleanly isolated.
Runs kicked off through MCP now start their own root trace instead of nesting under FastMCP's identity-less protocol span. Your traces attribute the work to the actual run, so observability for MCP-driven activity lines up with everything else instead of disappearing into a generic parent.
A new TwelveLabsTools toolkit lets your agents analyze videos and generate multimodal text embeddings, so video becomes something an agent can search, summarize, and reason over rather than a black box. Drop it in the way you would any other Agno toolkit.
See the TwelveLabs docs for setup.
A new SofyaTools toolkit gives agents search, extraction, and research in one place, so they can find sources, pull content, and dig into a topic through a single integration.
See the Sofya docs for more or check out the cookbook for a working example.
A new SearchApiTools toolkit wires up SearchAPI's Google, News, Images, and YouTube endpoints, so an agent can run several kinds of search from one toolkit instead of stitching together separate providers.
See the SearchAPI docs for more or view the cookbook for a working example.
The base Toolkit now takes a timeout, and HTTP timeouts are wired across the tools, with support extended to more toolkits. A tool that stalls on a slow or unresponsive endpoint now fails fast instead of holding up the run, giving you predictable behavior under real-world network conditions.
StudioTool is now StudioTools, bringing it in line with the plural naming the other toolkits use. A backward-compatible alias keeps the old name working, so existing code runs unchanged while you move to the new one at your own pace.
LocalFileSystemTools can now read files, not just write them, once you set the enable_read_file flag. By default it keeps every file operation inside your target_directory, so an agent stays within the folder you hand it rather than roaming the wider file system. Set restrict_to_base_dir=False to opt out when you deliberately need broader access.
See the Local File System docs for the full parameter list.
Land your traces in ClickHouse and let a column store built for analytics carry the load. It ingests heavy trace volume and runs fast OLAP scans, so aggregating and slicing observability data stays quick even as your run count climbs.
See the ClickHouse docs for setup.
Add the new Scavio toolkit to an agent and it gains Scavio-backed web search instantly, the same way it picks up any other Agno toolkit. It widens the set of search providers you can reach without writing a client.
Browse the Scavio tool docs for more info.
Grab the citations behind a grounded OpenAI answer directly from response.citations, now populated for the OpenAIChat and OpenAILike providers. You see exactly which web results the model used instead of parsing them out yourself.
Run AgentOS on FastAPI >= 0.137 and get_routes() returns every registered route. You get the full picture of your deployment when you introspect it, rather than a partial list.
Turn on native structured outputs and JSON schema outputs for LiteLLM per provider with supports_native_structured_outputs or supports_json_schema_outputs. Providers that can enforce a schema natively now do, so you get dependable structured responses without a cleanup pass.
See the LiteLLM structured output docs for usage.
Google toolkits now share one auth base class, so authentication works consistently across all of them. You get a cleaner, more predictable foundation and integrations that are easier to maintain.
Surface as many suggested prompts as your interface calls for. AgentOS drops the three-per-entity cap on quick_prompts, so you shape the list around your users instead of an arbitrary limit.
See the AgentOS configuration docs for how to set them.
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.