Skip to main content
GenosOS supports multiple agents running in parallel, each focused on a different domain. A main assistant can delegate to a dental clinic agent, a research agent, or a customer service agent — automatically, without the user doing anything special.

​
Why multiple agents

A single general-purpose agent works well for most tasks. Specialist agents are useful when:
  • A domain needs its own identity, memory, and tool profile (e.g., a patient-facing clinic assistant vs. a developer coding agent)
  • You want separate channel routing per audience (e.g., WhatsApp for patients, Slack for the internal team)
  • Security boundaries require isolation — one agent should not see another agent’s conversations

​
Agent-to-agent (A2A) communication

Agents communicate through an internal message bus. A2A is decoupled from visibility: two agents can exchange messages without sharing session history or being able to read each other’s memory.

​
How it works

When agent A needs to delegate a task to agent B:
  1. Agent A calls sessions_send with the target agent’s session key.
  2. The gateway validates that the target agent exists (agent existence guard — the call is rejected if the target is unknown).
  3. The message is delivered to agent B’s session with an inter_session provenance marker.
  4. Agent B processes the request and responds.
  5. The response is delivered back to agent A.

​
Input provenance

Every message an agent receives carries a provenance field:
ProvenanceMeaning
external_userThe message came from a human via a channel (WhatsApp, Telegram, etc.)
inter_sessionThe message came from another agent
Agents use provenance to adjust their behavior — a response to a human might include pleasantries, while a response to another agent can be terse and machine-readable.

​
Ping-pong turns

A2A exchanges use a ping-pong model: by default, 2 turns per exchange (configurable up to a maximum of 5). This prevents runaway loops where agents keep routing to each other indefinitely.

​
Control signals

Agents can send control signals to terminate an exchange early:
SignalEffect
REPLY_SKIPThe receiving agent skips generating a reply
ANNOUNCE_SKIPThe announcing agent suppresses its outbound announcement
These signals are useful when an agent determines that no further response is needed — for example, after logging a task or completing a fire-and-forget action.

​
Example: dental clinic delegation

A main assistant handles general requests. When a patient asks about appointments, the main assistant routes to a dedicated dental clinic agent that has calendar access, a patient CRM, and its own WhatsApp greeting. 
Patient (WhatsApp): "I'd like to reschedule my cleaning for next Tuesday"

Main agent:  Recognizes appointment request
             → delegates to "Clínica Dental Pozzi Assistant" via A2A

Dental agent: Checks Google Calendar for availability
              → finds an open slot at 10:00 AM
              → books the appointment
              → replies to the patient directly
The patient never knows delegation happened. The main agent never needed calendar access.

​
Setting up A2A

Create agents conversationally, then configure which agent delegates to which:
1

Create your specialist agent

Tell your assistant what you need:
"Create an agent for my dental clinic"
The agent is created with an appropriate tool profile and workspace.
2

Configure delegation

Tell the main agent which requests to route:
"When patients ask about appointments, delegate to the dental clinic agent"
The main agent’s AGENTS.md workspace file is updated with delegation rules.
3

Test the flow

Send a test message via the relevant channel. The main agent should route it without prompting.

​
Sub-agent spawning

For tasks that require parallel execution or dynamic delegation, the sessions_spawn tool creates a sub-agent on demand. Spawned agents:
  • Inherit the tool profile of the parent (unless overridden)
  • Are depth-limited — spawned agents cannot themselves spawn further agents without limit, preventing infinite loops
  • Run inside per-session Docker sandboxes when security policies require it (non-main sessions)
Sub-agent spawning is best for transient tasks — data processing, report generation, parallel research. For persistent specialist agents (clinic assistant, SEO agent), use named agents with A2A instead.

​
Security

  • Non-main sessions can run inside per-session Docker sandboxes, isolating sub-agent execution from the host.
  • Channel tool restrictions apply to each agent independently — a messaging-channel agent cannot run shell commands even when spawned by an agent that can.
  • A2A messages are stored encrypted in each agent’s own session transcript (NYXENC1).
The agent existence guard means a misconfigured delegation target fails loudly — the routing call is rejected before any message is sent to an unknown agent.