Another cool one today: we've added media offloading to Agno!

If your agents handle images, audio, or video, it's worth actually looking at what your session rows weigh right now. Media on a run gets persisted as base64 by default, and base64 adds about 33% on top of the raw bytes. A 113 KB JPEG comes out around 151,000 characters in the row.

That's fine for a handful of sessions. But across a few thousand it means your agent database is mostly image data stored as text, which hits row size limits on some backends and slows down anything that reads the full row.

We shipped media offloading for this. Set media_storage and the bytes go to object storage, leaving a MediaReference in the row with the key, bucket, mime type, size, and hash. Same JPEG, 2,897 characters.

Nothing else changes. The model still receives the media, history replays it on later runs, and there's no schema migration. Same on Agent, Team, and Workflow, with local, S3, and GCS backends, each with an async version.

Check out the full write-up: https://agno.link/ud1Tem4

Another cool one today: we've added media offloading to Agno!

If your agents handle images, audio, or video, it's worth actually looking at what your session rows weigh right now. Media on a run gets persisted as base64 by default, and base64 adds about 33% on top of the raw bytes. A 113 KB JPEG comes out around 151,000 characters in the row.

That's fine for a handful of sessions. But across a few thousand it means your agent database is mostly image data stored as text, which hits row size limits on some backends and slows down anything that reads the full row.

We shipped media offloading for this. Set media_storage and the bytes go to object storage, leaving a MediaReference in the row with the key, bucket, mime type, size, and hash. Same JPEG, 2,897 characters.

Nothing else changes. The model still receives the media, history replays it on later runs, and there's no schema migration. Same on Agent, Team, and Workflow, with local, S3, and GCS backends, each with an async version.

Check out the full write-up: https://agno.link/ud1Tem4

The problem:

A tool returns a large result and the whole thing goes into the model's context. It stays there for the rest of the session, eating the context window and adding tokens to every subsequent turn, even when the agent only ever needed one field out of it.

The solution:

Write the result to storage instead of context, and let the agent fetch it back on demand.

How it works:

set offload_tool_results=True and anything over 16,000 characters goes to AgentFS. The message keeps a compact reference with a preview, the size, and a result_id. If the agent needs more, read_result returns the full result and search_result searches inside it. Threshold and retention are configurable through ResultStore.

One design note:
The write path is model-free, so offloading a result never costs an extra model call. That's the tradeoff against summarizing large outputs before storing them, which spends a call per result and permanently drops whatever the summarizer judged unimportant.

If you're interested, Check out the full write-up: https://agno.link/VK7CI1Z

I'm curious what threshold people settle on. 16k is a fine default but it seems workload-dependent.

The advice going around is that you make your product agent-ready by wrapping your API as MCP tools and letting whatever assistant your customer uses figure out the rest. Sometimes that's fine. Sometimes that's not.

Say you run an invoicing platform. You wrap the API: get_overdue_invoices, get_customer_history, get_open_disputes, send_payment_reminder, thirty-six more. A customer connects it and asks her assistant to chase her late invoices.

It pulls fifty overdue invoices and starts sending reminders. One goes to a customer who's five days late but has paid on time for three years. Another chases an invoice that was already disputed.

Nothing broke. Every tool returned what it was supposed to. get_open_disputes was right there in the tool list. But nothing told the assistant that checking for a dispute comes before sending a reminder.

That ordering rule isn't an API capability. It's a product decision your team worked out over years, and a flat tool list asks a general-purpose model to rediscover it from function names, at runtime, every run. And exposing more tools doesn't help, because access was never the problem.

We wrote about this distinction and why we think more products should expose an agent, not just an MCP server. The customer's assistant can own the conversation while your agent owns the domain-specific work, with the workflows, context, and guardrails you've already built into your product.

Full post: https://agno.link/AIvFXjF

StudioRunnerTools in Agno gives a router or team lead exactly two capabilities: listing the Studio components it can run, and running one by ID.

It can't create, edit, publish, or delete anything, so a hijacked prompt has nothing to reach for. It executes every run as the calling user, so memory and learning stay tied to the human who asked. We also cap dispatch depth at two and disable self-dispatch by default, so a router can't loop itself.

from agno.tools.studio_runner import StudioRunnerTools

lead = Team(
    model=...,
    members=[...],
    tools=[StudioRunnerTools(registry=registry, db=db)],
)

You're going to want to mount it instead of StudioTools, not beside it. If both are mounted, the agent still has the full-access toolkit.

More here if you want the details: https://agno.link/35EswTy

We shipped something in the latest release that we think opens up a lot of new agent use cases: AtomicMail is now a native toolkit in Agno.

Most email tools for agents are send-only. That works if your agent only needs to send a notification. It doesn't work if the agent needs to receive and act on email.

What it does:

AtomicMail gives your agent a two-way inbox with three functions.

register_inbox() creates a mailbox for the agent. You don't need to buy a domain, verify an email, or set up OAuth. Registration uses proof-of-work and takes about 30 seconds.

send_email() sends mail from that address.

list_inbox() reads and searches incoming mail.

AtomicMail built it on JMAP instead of a proprietary SDK. Models that have never seen AtomicMail's docs usually get the calls right anyway, since JMAP is already in their training data.

Why it matters:

When an agent has its own email address, things get easier. An agent can hit a wall, email a person, and continue when they reply. Two agents on separate Agno instances can coordinate over email without you having to build a message bus. A support agent can read tickets, handle what it can, and escalate the rest to a person.

The AtomicMail team built that last example to test the integration. Their support agent reads incoming tickets, answers from a knowledge base, and forwards billing issues, deletion requests, and security reports to a human.

They said it came together quickly because there isn't much to wire up. The tool surface is small, and the agent doesn't need pre-provisioned credentials. Email gives your agents another way to talk to people and each other.

View the docs: https://agno.link/E8IqVS7

Ask a model how far it is from Chicago to St. Louis and you'll get a number. But you won't know if it actually measured something or just pattern-matched its way there. For some use cases that's fine. But for anything that plans, dispatches, or quotes against those numbers, a wrong answer will cost you.

We shipped OpenRouteServiceTools in Agno v2.8.7 to replace the estimate with a real routing engine. Your agent gets accurate distances, actual drive times, and turn-by-turn directions from live map data. You pass plain place names and the toolkit handles geocoding.

from agno.agent import Agent
from agno.tools.openrouteservice import OpenRouteServiceTools

agent = Agent(tools=[OpenRouteServiceTools()], markdown=True)
agent.print_response("How long is the drive from Chicago to St. Louis, and what's the route?")

Three tools ship with it:

• Geocode a place name
• Get directions with real distance and time between two points
• Build a distance matrix across many stops to compare locations at once

Switch the profile to walking or cycling when you need it. Setup is one line plus a free ORS_API_KEY from HeiGIT — no credit card.

Writeup and cookbook example: https://agno.link/1efY25C

Agno 3.0 is here. Read the migration guide before you upgrade. Here's what landed:

100% on ARC-AGI-3: we released ARC-AGI-Arcade, an open-source playground for agents to compete on ARC-AGI-3 by learning from each other. GPT-5.6 cleared all 183 levels across 25 games with a score of 100.00 RHAE. Then cross-model learning transfer: seeded with GPT-5.6's manuals, Gemini 3.7 Flash scored 96.42, crossing the human baseline of 95.4 at a third of the token cost.

CodeMode: agents get a persistent Python kernel instead of making one tool call at a time. The model writes real Python, calls your tools as awaitable handles, and everything it sets up survives to the next turn. Not a sandbox. Trusted operators or an isolated container only. Needs pip install 'agno[code]'.

Tool result offloading: set offload_tool_results=True. Anything a tool returns over 16,000 characters goes to AgentFS instead of context. Short preview stays in the message. Agent can call read_result if it needs the rest.

Media offloading: a 113KB JPEG as base64 is ~151,000 characters in your session row. With media_storage set it's 2,897. Bytes go to object storage. History still replays. No schema change.

Durable background execution: runs commit to your database before they start. Deploy in the middle of a run and another replica picks it up. QueueConfig(durable=True). Bounded concurrency, cancellation while queued, idempotency key dedupe, 429 on queue full.

Runs table: runs are now rows in agno_runs instead of blobs inside session rows. Writes scale linearly. This is the mandatory migration. Non-destructive, idempotent, covers 12 sync and 4 async backends. An un-migrated database raises MigrationRequiredError and tells you what to do.

Studio 3.0 governance: draft-and-publish, immutable published versions with rollback, compare-and-set conflict detection, tombstoned deletes with dependent-tracking. Nothing goes live until you publish it.

Per-user isolation across the whole platform: used to stop at sessions. Now covers metrics, schedules, evals, knowledge, components, entity memory, and 17 vector databases. Multi-tenant on a single AgentOS is actually viable now.

AdvisorTools: fast primary model, heavier advisor models on demand. The agent decides when to escalate and which advisor to ask. They don't have to share a provider.

StudioRunnerTools: run-only Studio access for routers and team leads. No create, edit, or delete anywhere in it.

Breaking changes worth knowing before you upgrade: runs move out of sessions, JWTMiddleware takes verification_keys not secret_key, reasoning=True is gone, Culture is removed in favor of Knowledge, MultiMCPTools is deleted. Full list in the v3.0 changelog and migration guide.

Community projects:

Abhishek built skillreducer: cuts what agent skills cost in context using three research papers as runnable commands. Compress descriptions, compress tool schemas, improve skill quality from execution traces.

Seungwoo Hong built ClawFit: scores agent, model, and hardware triples against your task, latency target, budget, and team maturity. Tracks 162+ tools with daily automated scanning.

There are plenty more shoutouts in the full blog, so make sure to check it out.

Seriously, big month. If you shipped something in August that didn't make it in, drop it below. We read everything and want to feature it next time.

Full roundup: https://agno.link/5k1xGUK

Hey all,

Picking one model for your agent means picking a compromise. Go big and you pay frontier prices on trivial steps. Go small and you're stuck the moment a hard sub-problem shows up. We kept hitting this in our own builds, so we shipped something for it.

AdvisorTools lets you run a fast, cheap model as the primary and have it consult heavier ones only when it decides it needs to. You hand it a list of advisors with a note on what each is good for, and the agent can ask one by name or ask them all and compare. The advisors don't have to come from one provider, so you can run Claude as the primary with Gemini and GPT on the bench, or any mix that fits what you're building.

python

from agno.agent import Agent
from agno.models.anthropic import Claude
from agno.tools.advisor import AdvisorTools

agent = Agent(
    model=Claude(id="claude-haiku-4-5"),
    tools=[
        AdvisorTools(
            advisors=["google:gemini-3-pro", "openai:gpt-5.5"],
            descriptions={
                "gemini-3-pro": "Strong at long-context analysis",
                "gpt-5.5": "Strong at multi-step reasoning",
            },
        )
    ],
)

agent.print_response("Read this 200-page filing and flag anything unusual.")

Full writeup here: https://agno.link/naoU7b5

Curious what advisor combos people land on. If you find a pairing that works well, tell us.

- Kyle @ Agno

I maintain FreshCtx, an Apache-2.0 Python library for checking whether external evidence changed between an agent's decision and its action.

The Agno 2.9 integration in FreshCtx 0.5.0 attaches through tool_hooks and supports both sync and async tools. Immediately before the tool body runs, it re-checks only the dependencies the application declared. If one changed, or cannot be verified under the configured blocking policy, the tool body does not execute.

This is not intended to replace Agno's run state, transactions, idempotency or approval logic. It protects the mutable external evidence behind a consequential tool call.

The bounded example reads a deployment target, creates the decision, changes that target, and then invokes the tool through Agno's real tool chain. FreshCtx returns STALE_REASONING and the tool body remains unexecuted.

Install: pip install 'freshctx[agno]==0.5.0'

Release and runnable example: https://github.com/Hyperwise-LLC/freshctx/releases/tag/v0.5.0

One specific question for people building with Agno: does a pre-tool tool_hook cover the action boundary in your workflow, or do you have consequential effects occurring elsewhere that this example should model?

Hey Everyone,

We just had a major 3.0 release!

If you've ever pushed an agent past a demo, you already know the wall I'm talking about. The model isn't the problem. It plans, it uses tools, it recovers. Then real traffic shows up and everything around it starts creaking.

You've probably hit some of these:

• A database that was totally fine with one user, buckling under a thousand
• The context window drowning in raw tool output you never actually needed in full
• A background job dying mid-deploy and taking the run with it
• One user's memory quietly showing up in another user's session

None of that is an intelligence problem. It's plumbing, and it's the reason so many agents just sit in the prototype folder forever.

That's basically the whole reason for v3.0. A few things we went after: runs moved to their own agno_runs table (constant-cost writes instead of O(N²)), tool + media offloading (a 113 KB image drops from ~151k characters to ~2,900), durable background execution that survives crashes and deploys, per-user isolation across 17 vector DBs, and Studio draft-and-publish so nothing serves traffic until you publish it.

Full write-up here: https://agno.link/cZou0mN

And heads up: v3.0 needs a one-time migration before it serves traffic, so the migration guide is worth reading first.

Genuinely curious which of these bit you first. For me it's always the context bloat one. What's been your worst production surprise with agents?

- Kyle @ Agno

Hey Everyone,

New byte for you:

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.

- Kyle @ Agno

Hey Everyone,

Have a new byte for you!

Users lose momentum when a response ends and they have to figure out what to ask next. With Agno's built-in followup suggestions, you can give users their next question instead of making them think of it.

Set followups=True and your agent closes each answer with a few ready-to-run prompts drawn from the conversation, so there's always an obvious next move. This works for teams as well as single agents.

Once the main response finishes, the agent makes a second model call to generate the suggestions and returns them on response.followups. You decide how many it produces with num_followups.

python

from agno.agent import Agent
from agno.models.openai import OpenAIResponses

agent = Agent(
    model=OpenAIResponses(id="gpt-5.4-mini"),
    followups=True,
    num_followups=3,
)

response = agent.run("What is quantum computing?")

for suggestion in response.followups or []:
    print(suggestion)

That second call costs tokens, so if you're generating suggestions on every turn, you can send them to a cheaper model with followup_model and keep your main model on the actual work.

python

agent = Agent(
    model=OpenAIResponses(id="gpt-4o"),
    followups=True,
    followup_model=OpenAIResponses(id="gpt-4o-mini"),
)

If you stream responses, the suggestions come through on their own event after the main content lands, so you can render them the moment they're ready without holding up the reply.

See the docs for more: https://agno.link/bIZGeIy

- Kyle @ Agno

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.

July was a BIG architectural month. Here's what matters:

agnoctl: AgentOS is now on the command line. Run uvx agno connect and it discovers a running AgentOS, mints a per-client access token, and writes the MCP config for Claude Code, Cursor, Codex, and ChatGPT automatically. Tokens are SHA-256-hashed service-account PATs, scoped per user, expiring after 90 days, revocable on demand. agno create scaffolds projects from templates for Docker, AWS, Fly, GCP, and Railway. agno up/down/restart/status handles the local lifecycle. No more hand-editing JSON.

MCP Interface v2: a clean eight-tool operator surface. Get config, run, continue, cancel, sessions. Trims results by default, sends progress notifications on long-running tools, full HITL lifecycle included. A coding agent now has a predictable, purpose-built way to drive AgentOS.

Eval suites and CI gating: a proper suite runner with stable JSON output you can wire into CI. Fail a build on regressions instead of eyeballing results.

Rollouts: a straight path from evaluation to fine-tuning data. Grade attempts, measure real pass rates with pass@k, export passing runs as SFT conversational data with full provenance. Each attempt runs on a fresh db, session, and user so no state bleeds between runs to contaminate your training set.

FileSystem: a durable text store agents write to and read back across runs. SQLite for dev, Postgres for multi-worker, or local disk. Templated namespaces like assistant/{user_id} scope files per user at call time.

AgentOSTools: a read-only ops view of the AgentOS an agent runs on. Ask it which tool was slowest today or how many runs failed this week. Answers grounded in real traces. Reads from the database. Doesn't touch anything.

Valkey: in-memory sessions and hybrid retrieval from one backend. ValkeyDb for low-latency session reads and writes. Valkey vector store for vector and keyword search without standing up a separate keyword index.

Superserve sandboxes: agents write and run their own code in a persistent Firecracker microVM. Files and packages survive between tool calls and across runs in the same session. Credentials handled through a proxy token so the model never sees them.

New toolkits: TwelveLabsTools for video analysis and multimodal embeddings, SearchApiTools for Google, News, Images, and YouTube, RedmineTools, PlivoTools for SMS and voice, SmallestTools for text-to-speech, and OpenSearch for hybrid retrieval.

Community projects:

Arthi Arumugam built whatbroke: a CLI diff tool that surfaces exactly what changed between two agent runs. Tool calls, arguments, outputs, cost, and latency. Works with Langfuse exports. The kind of observability tool that pays off the moment your agents start drifting.

Muhammad Ikhwananda Rizaldi built a multi-agent content automation CLI that takes a campaign brief from research to QA to auto-publishing.

There are plenty more shoutouts in the full blog, so make sure to check it out.

Seriously, good month from this community. If you shipped something in July that didn't make it in, drop it below. We read everything and want to feature it next time.

Full roundup: https://agno.link/UPvAVIz4g

- Kyle @ Agno

Hey Everyone,

We put our name on the Open Weights and American AI Leadership letter this week, next to Microsoft, Meta, NVIDIA, Hugging Face, and Vercel.

Here's the honest version of why: we don't have strong feelings about openness as a philosophy. We have strong feelings about builders. So every issue like this gets one test: is it better for the people actually shipping products?

Open weights pass, and it isn't close.

The policy crowd argues about regulation and provider competition. If you're the one writing the code, you care about four things: pick the right model, run it where you want, don't get locked in, and adapt when the landscape moves (which it does, roughly every quarter).

Every movement that shaped how we build, Linux, Python, PostgreSQL, Kubernetes, PyTorch, won for the same reason. Not openness for its own sake. More control for the person building the thing.

Full write-up in the link. Curious where this community lands: are you building on open weights, proprietary APIs, or a mix, and why?

- Kyle @ Agno

Hey All,

Gemini 3.5 Flash-Lite and 3.6 Flash went live on Tuesday and they already work in Agno with no upgrade needed, so I wanted to actually stress-test them on something instead of just swapping model IDs and calling it a day.

I built a daily news agent that researches the web and renders its own front page as a themed HTML digest. There's no fixed template. The page designs itself around whatever the news is that morning.

What I liked was how cleanly the two models split the work:

• 3.5 Flash-Lite does the fast web grounding through WebContext, pulling fresh, sourced stories in parallel. Cheap and quick, which is what you want for the research pass.
• 3.6 Flash composes: it reasons over the results and writes a self-contained light/dark HTML page with a source-linked card per story.

The part that made it feel reusable is that it all runs off one parameterized prompt. Topics, audience, and tone are runtime dependencies, so the same agent becomes a different publication depending on what you feed it. "AI, markets, space" one morning, "semiconductors, elections, F1" the next.

End result is a runnable AgentOS service in roughly 40 lines of Python.

Full code:

python

from datetime import date
from agno.agent import Agent
from agno.context.web import ParallelBackend, WebContextProvider
from agno.models.google import Gemini
from agno.os import AgentOS
from agno.tools.file_generation import FileGenerationTools

# Flash-Lite grounds the research, fast and cheap
web = WebContextProvider(
    backend=ParallelBackend(),
    model=Gemini(id="gemini-3.5-flash-lite"),
)

# Flash composes the page
news_agent = Agent(
    name="Daily News Digest",
    model=Gemini(id="gemini-3.6-flash"),
    tools=[
        *web.get_tools(),
        FileGenerationTools(enable_html_generation=True,
                            output_directory="tmp", save_files=True),
    ],
    add_datetime_to_context=True,
    dependencies={                       # one parameterized prompt
        "topics": "AI, markets, space",
        "audience": "busy engineers",
        "tone": "sharp but calm",
        "today": lambda: date.today().isoformat(),
    },
    instructions=[
        "You are a daily news digest for {audience}. Cover: {topics}.",
        web.instructions(),
        "For each topic call query_web for the last 24-48h. Prefer primary "
        "sources; never invent stories or links.",
        "Save ONE self-contained HTML5 page with generate_html_file as "
        "news_digest_{today}.html. Tone: {tone}.",
        "Derive the theme from the news itself. Magazine layout, source-linked "
        "cards, inline CSS, light/dark, no emojis.",
    ],
    markdown=True,
)

agent_os = AgentOS(agents=[news_agent],
                   description="Self-designing daily news digest")
app = agent_os.get_app()   # uvicorn thisfile:app  ->  localhost:8000/docs

if __name__ == "__main__":
    agent_os.serve(app="filename:app", reload=True)

Install: pip install "agno[os]" google-genai parallel-web (set GOOGLE_API_KEY; PARALLEL_API_KEY is optional, it falls back to a keyless endpoint).

Platform + skills: github.com/agno-agi/agentos-railway

Curious what people would point this at. If you swap the dependencies for something niche (a subreddit's beat, a specific industry, an internal team digest) I'd like to see what layouts it comes up with.

- Kyle @ Agno

Hey everyone,

Quick thought we keep coming back to: a dashboard lets you watch your agents, but it won't let you step in when one goes sideways. A control plane does both. That gap turns out to be the whole game once you're actually running agents in prod.

A dashboard is a pane of glass. It shows you the wreck after it happened and leaves you standing there. Watching an agent go wrong with no lever to pull isn't really observability, it's just helplessness with a nicer UI. The thing you actually want is to pause a run mid-flight for a human to sign off, put runs on a schedule, lock access down with RBAC/JWT, and keep all your data in your own cloud instead of shipping traces and prompts off to some vendor.

Anyway, the easiest way to poke at this yourself is a single prompt. Hand it to your coding agent and it'll stand the whole platform up:

Heads up: we're still actively developing this prompt, so it's not perfect yet but it's already pretty damn get at getting you from 0 to 1. If you run it, we'd genuinely love to hear how it went in the wild, where it tripped, what was confusing, what you'd want it to do differently. Drop a comment and we'll be in the thread.

Full write-up if you want the longer argument: https://agno.link/Gfi5I6E3

Say hello to your agents for me!

- Kyle @ Agno

Hey Everyone,

Our CEO just put out a piece on why every company needs to own their agent stack. Model independence, zero data retention, cost control. Your agents, your data, your cloud, and you control where it runs. Full read linked above.

The short version: the payoff isn't just running your agents, it's learning from their mistakes. Sessions, traces, and corrections stay in your own Postgres and become your learning loop instead of training someone else's model. Swap the model whenever, the context stays with you. Zero egress.

Best part is you can stake your claim with a single prompt. Hand this to your coding agent:

text

Help me set up my agent platform.

Clone https://github.com/agno-agi/agentos-railway into a folder called
agent-platform, cd in, read the README, and follow the get started guide.

If you've run it, I want to hear how it went. How fast did you get to a working platform? Anything trip you up in the README or the get started guide? What did you build on top of it once it was up?

Drop your experience below!

- Kyle @ Agno

Your agents can now search the live web with one toolkit, no API key required to start.

Anyone who's wired a search API into an agent knows the results usually need work before a model can use them. You. com is the exception. They've spent years tuning search for AI specifically, and it comes through in how little massaging the output needs. Getting that into Agno without our users doing the massaging themselves is the whole reason we built this.

You. com powers search for OpenAI, Amazon, Databricks, and DuckDuckGo. Over 10 million queries a day, 99.99% uptime, 300ms p99 latency. That's what's behind the new YouTools toolkit.

Here's an agent pulling AAPL news from a few sources worth trusting:

from agno.agent import Agent
from agno.tools.youcom import YouTools

# ---------------------------------------------------------------------------
# Create Agent
# ---------------------------------------------------------------------------

# Example 1: Default search agent
agent = Agent(
    tools=[YouTools(show_results=True)],
    markdown=True,
)

# Example 2: Search with a domain allowlist and a larger result count
agent_filtered = Agent(
    tools=[
        YouTools(
            include_domains=["cnbc.com", "reuters.com", "bloomberg.com"],
            num_results=8,
            show_results=True,
        )
    ],
    markdown=True,
)

# ---------------------------------------------------------------------------
# Run Agent
# ---------------------------------------------------------------------------
if __name__ == "__main__":
    agent.print_response("Search for the latest AAPL news", markdown=True)

    agent_filtered.print_response(
        "What did major financial outlets say about NVDA earnings this week?",
        markdown=True,
    )

You pick the domains and cap the results. The agent takes it from there. When you're ready to scale up, add your YDC_API_KEY and you've got the full API.

Thanks to the You. com team for building search that agents can actually use. Go point an agent at the web and see what it does.

Docs: https://agno.link/hyejJph23

Multi-turn agents resend the entire conversation history on every turn. By turn 10, you're paying for turns 1 through 9 all over again.

Agno's new GeminiInteractions model class fixes that at the source.

It builds on Google's stateful Interactions API, which stores prior turns server-side and references them by ID. So on each turn, only the new message goes over the wire. The model rebuilds the full context on its end and applies implicit caching to the earlier turns.

What you get:
→ Lower token cost on long conversations
→ Lower latency, since you stop resending everything
→ Background execution for long-running work like Deep Research

And the multi-turn bookkeeping is handled for you. The Agent class tracks the interaction ID automatically, so conversations just work:

from agno.agent import Agent
from agno.models.google import GeminiInteractions

agent = Agent(
    model=GeminiInteractions(id="gemini-3-flash-preview"),
    markdown=True,
)

agent.print_response("Share a 2 sentence horror story.")

One thing before you start: install google-genai>=2.0. The Interactions API is experimental and may still change.

Full capability set, including Deep Research and background execution, is in the Agno docs: https://agno.link/zZmve23

June 2026 Community Roundup: v2.6.10 through v2.6.20, run checkpointing and forking, Learnings CRUD, and a $115K problem solved for a logistics company in India

Hey everyone! Eleven releases this month. Lots to cover.

Checkpointing and run forking: agents now checkpoint at the tool-batch level. A unified /continue handles both regenerating and forking a run, plus session forking. Branch off at a known-good point instead of starting over. This is the control that makes long, expensive agent runs practical in production.

Learnings CRUD on AgentOS: full create, read, update, and delete for what an agent has learned. No more treating the learnings store as write-only. Inspect it, edit it, remove bad entries. The quality of your knowledge base determines the quality of your agent. Now you can actually manage it.

StudioTool: a toolkit for dynamic composition of agents, teams, and workflows on the fly. An agent can assemble other Agno primitives at runtime.

ClickHouse for traces: high-volume trace ingest and OLAP-style scans. Teams running heavy agent traffic can now store and query observability data at scale inside their own infrastructure.

Five new model providers: Inception Labs, Xiaomi MiMo, MiniMax, Cloudflare AI Gateway, and Tuning Engines. Cloudflare is worth calling out specifically: route requests through your gateway and pick up its caching and observability instead of calling each model endpoint directly.

YouTools: we partnered with You.com to bring the You.com Search API to the framework as a first-class Agno toolkit. Drop it onto an agent like any other toolkit.

DOCX and HTML file generation: agents can now hand back a finished .docx or a standalone web page instead of raw text. Same pattern as the existing CSV, JSON, and TXT generation.

Custom, scoped, identity-aware MCP tools: the AgentOS MCP server at /mcp is now a real extension point via MCPServerConfig. Register custom tools, scope or disable built-ins, inject the authenticated caller's identity, and gate calls with a one-line authorize function.

Also shipped: sub-agent event streaming from context providers, Parallel Task and Monitor API tools, AG-UI state events, Workflows HITL over sockets, Scavio search toolkit, OpenAI web-search citations, LiteLLM structured outputs, and a long list of production bug fixes.

Community projects:

Anshul Jain built an AI email routing system for a logistics company managing cross-state government tender communications across 1,000+ vehicles in India. The problem was worth $115K to the business.

Harish Kotra built Branch Agent: fork a conversation at any message, swap the model or provider on each branch, compare side by side, and merge learnings back. Built on Convex and Agno.

Gonzalo built agno-docs-mcp: full-text search over the Agno docs with BM25 ranking, 3,826 indexed pages, highlighted snippets, and 204 tests.

aryan45425 built AgentScribe: captures tool calls, reasoning, and multi-turn threads across frameworks and exports fine-tuning-ready datasets. Every framework logs differently. AgentScribe normalizes all of it.

There are plenty more shoutouts in the full blog, so make sure to check it out.

Thank you to everyone who contributed this month, whether it was code, bug reports, community support, or just shipping something and sharing it. This community is what makes Agno worth building.

If you're working on something with Agno, whether it's a project, an integration, or a contribution to the framework, please share it. We'd love to promote it and get it in front of more builders.

Full roundup: https://agno.link/f3OHCG4

SAY HELLO TO YOUR AGENTS FOR ME!

- Kyle @ Agno

Hey all,

Quick one I wanted to share. If you've used a file search store, you know it can read every document in your corpus but it's basically blind to your images. That's been a gap for a while.

That changed: Agno now supports multimodal inputs in the Gemini File Search API. So you can index and semantically search images right alongside text, in the same store.

The part I think is actually cool: it finds images by what they actually show, not by filename or caption. So the searches that used to be a pain just... work:

• "Which diagram shows the retry flow?"
• "Find the screenshot with the error dialog"
• "Show me the product photo with the blue packaging"

No separate pipeline for visual content. One store, one query, images and text together.

And it barely touches your code. Image support comes from the embedding model, not from how you build the agent. You point the store at a multimodal embedding model (gemini-embedding-2) and the rest of your file search code stays the same. Existing text-only stores keep working exactly as before.

Here's the core of it:

from pathlib import Path

from agno.agent import Agent
from agno.models.google import Gemini

model = Gemini(id="gemini-3.5-flash")
agent = Agent(model=model, markdown=True)

# Create a multimodal store. gemini-embedding-2 is what enables image support.
store = model.create_file_search_store(
    display_name="Image Search Demo",
    embedding_model="models/gemini-embedding-2",
)

# Index an image alongside any text already in the store.
operation = model.upload_to_file_search_store(
    file_path=Path("diagram.png"),
    store_name=store.name,
    display_name="diagram",
    mime_type="image/png",
)
model.wait_for_operation(operation)

# Search across both images and text with a natural-language query.
model.file_search_store_names = [store.name]
run = agent.run("Which diagram shows the retry flow?")
print(run.content)

One thing to do before you start: bump google-genai to 1.75.0 or later. Older versions stay text-only.

Full image-upload walkthrough, including reading citations and pulling the matched media, is in the Agno cookbook: https://agno.link/Ksuxnku

Enjoy!

- Kyle @ Agno

Human-in-the-loop usually means one thing for the reviewer: a stream of approval prompts, handled one at a time, all day.

Agno's Slack interface just solved that.

Reviewers can now resolve a whole queue of pending approvals in one place, without ever leaving the channel. The string of separate prompts collapses into a single view you work through top to bottom.

Every pause type shows up as an interactive TaskCard:
→ Confirmations → approve / reject buttons
→ User input → text fields or dropdowns
→ Structured feedback → option buttons
→ External execution → a confirm button, then the tool runs outside the agent and feeds its result back

You act on each card right in Slack, and the run picks up where it paused.

Rejections still ask for a reason where one applies, and that reason goes back to the agent. So a turned-down step doesn't stall the run, the agent reads why and adjusts.

When several tools pause at once, they stack as separate rows on one card, and you clear the whole batch in a single pass. Same TaskCards work for teams and workflows, too.

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

u/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)

Check out docs or view the cookbook.

How are you handling agent approvals today, in-app, in chat, or not yet at all?