[Python SDK] Make it easier for running without control-plane + networking

[pocesar]

Summary

Currently, my setup contains 6 isolated agents and deployed individually.
They don't share the same codebase, but live in a monorepo.
To be able to use all of them locally I need to collect each individual generated agent (through Agent(...)), patch their .call to lookup a table of agents (node_ids + reasoners + skills) to be able to call each other bypassing the internal Control Plane request mechanism.

lookup: Dict[str, agentfield.Agent] = {}
# collect and place them into lookup dict

agent_id = agent.id

async def _call(target: str, *args, **kwargs):
   node_id, reasoner_or_skill  = target.split(".", 1)
   if node_id != agent_id and node_id in lookup:
     return await lookup.get(node_id).call(target, *args, **kwargs)
   entry = agent._skill_registry.get(reasoner_or_skill) or agent._reasoner_registry.get(reasoner_or_skill)
   if entry is None:
      raise ValueError(f"Invalid target '{target}'")
   return await entry.func(target, *args, **kwargs)

agent.call = _call

Proposed solution

Ideally, having the AsyncExecutionManager to be able to collect many agents and orchestrate the calls between them, without the ConnectionManager doing the requests.
Make the AEM decoupled from the network.
It could be enabled by adapters that will keep the executions in memory but won't do any requests. By default it will use the current ConnectionManager delegation. But you can swap to a MemoryManager instead.

This is ideal to deploy mini versions that will live as a monolith instead of full separated deployments living in different machines.

Alternatives considered

Additional context

[AbirAbbas]

Triage

Classification: feature ✓
Suggested labels: enhancement

Likely affected files:

• ./reasoners/models.py (matched: reasoners)
• ./reasoners/init.py (matched: reasoners)
• ./reasoners/conversational.py (matched: reasoners)
• ./reasoners/helpers.py (matched: reasoners)
• ./reasoners/repo_config.py (matched: reasoners)

---

Triage by github-buddy

[santoshkumarradha]

Hey @pocesar thanks, this is a nice feature ask.

I think the useful distinction here is logical grouping vs process grouping.

Today, routers give us logical grouping: many reasoners organized under one AgentField node. Your use case is different if i am getting it right, you already have several logical AgentField nodes, each deployable on its own, but you want to group them into one Python process for local dev or a small embedded deployment ( i am assuming this is different than organizing it as router because you still want logical grouping as agents yet also have flexibility of process grouping while router makes them coupled, is that right ?)

Something like:

mesh = AgentMesh([agent_a, agent_b, agent_c])
mesh.run()

Then existing code keeps working:

await agent_a.call("agent-b.some_reasoner", input=...)

In mesh mode, .call would resolve against the mesh’s in-process agent registry instead of the network request path. If the target is not in the mesh, it should fail clearly.

A few constraints I’d want to preserve:

• Keep node.reasoner as the public contract, not direct Python imports.
• Keep the control plane focused on individual logical nodes, not a new “mesh” node.
• Treat the mesh as process topology only: many agents hosted by one process.
• Preserve .call semantics as much as possible: target lookup, dict/JSON boundary, parent-child execution context, and workflow events where available.

So I am in line with the feature request, I’d probably model this as an SDK-level AgentMesh / embedded call transport, with AsyncExecutionManager reused internally if helpful and across tsx/go

Let me know if this makes sense and i will open a feature issue.

cc: @AbirAbbas