# StudioRunnerTools brings identity-aware dispatch to any router or team lead

> New StudioRunnerTools hands out run access on its own: tools to list the components an orchestrator may run and to run one by id, with no create, edit or delete anywhere in the toolkit. Dispatched runs execute as the calling user.

- Published: 2026-08-13
- Author: Agno Team
- Categories: Changelog
- Canonical: https://www.agno.com/articles/studiorunnertools-brings-identity-aware-dispatch-to-any-router-or-team-lead
- Markdown: https://www.agno.com/articles/studiorunnertools-brings-identity-aware-dispatch-to-any-router-or-team-lead.md

Say you've built some agents and workflows in the Studio, and now you want a team lead or router to run them, on behalf of whichever user is asking. The only way to do that has been to give it `StudioTools`, the full builder toolkit, which can also rewrite and delete those components. That's a lot of power to hand a component that decides what to do at runtime. One bad plan or a prompt injection, and something meant only to dispatch work could edit or delete a production agent instead.

Our new `StudioRunnerTools` gives out run access on its own. It exposes exactly two things: tools to list the components an orchestrator is allowed to run, and tools to run one by id. There's no create, no edit, no delete in the toolkit at all, so even a hijacked prompt has nothing to reach for. You mount it on whatever dispatches the work, a team lead or a router, and the worst it can do is kick off a run.

```python
from agno.models.openai import OpenAIResponses
from agno.team import Team
from agno.tools.studio_runner import StudioRunnerTools

lead = Team(
    model=OpenAIResponses(id="gpt-5.5"),
    members=[...],
    tools=[StudioRunnerTools(registry=registry, db=db)],
)
lead.print_response("Run the invoice-parser agent on this month's uploads.")
```

The identity handling is what makes this safe for real users. A dispatched run executes as the current user: the wielding component's run context is injected and its `user_id` passed through, so memory and per-user state land on the person who actually asked instead of a shared service default. Each target also keeps one session per calling conversation, so a repeat run picks up where the last one left off rather than starting cold, and a paused run relays its human-in-the-loop requirements with the `run_id` and `session_id` needed to resume it.

Let an orchestrator run your building blocks while the ability to rewrite them stays locked away, and every run it fires off stays attributed to the right user. Mount it instead of `StudioTools`, not beside it, since `StudioTools` already embeds this same runner.