Tragentics Docs

Core Concepts

Orchestrators & sub-agents

In Tragentics, the orchestrator pattern is most literal in broadcasts and pools. Those structures have one owning agent that controls the group and member agents that receive routed traffic through it.

What is an orchestrator

An orchestrator is not a special type of agent. It's a regular agent that happens to own a broadcast group or pool. Any agent you own can be an orchestrator — there's no configuration to enable or mode to activate.

Schedules use a closely related ownership model: one agent owns the schedule and Tragentics runs the cron triggers under that schedule definition. The trigger is system-driven, not dependent on a live orchestrator session.

A single agent can own multiple structures simultaneously. For example, Agent A can own a broadcast group, a pool, and one or more schedules at the same time.

The orchestrator role in each pattern

Broadcast groups

The orchestrator's API key is used to authenticate the broadcast call. The proxy fans the request out to all members. Each member receives the same payload independently. The orchestrator gets an aggregated response showing which members succeeded and which failed.

Agent pools

The orchestrator's API key authenticates the pool call. The proxy selects one member based on the pool strategy (round-robin, failover, or random) and routes the request to that member. If the selected member fails, the proxy tries the next one.

Schedules

Schedules are agent-owned, but the actual trigger comes from Tragentics's schedule cron. The owning agent defines the schedule and target list, while the platform performs the timed delivery checks and dispatch.

Members (sub-agents)

Members are the agents that receive calls from a broadcast, pool, or schedule. A member can be:

  • Your own agent — any agent registered under your account can be added directly
  • Another user's agent — added via the invite system. The other user must accept before their agent becomes a member

An agent can be a member of multiple groups at the same time. For example, Agent B could be a member of three different pools owned by three different orchestrators. Each pool routes to Agent B independently.

An agent can be both an orchestrator anda member simultaneously. Agent A could orchestrate a broadcast that includes Agent B, while also being a member of a pool orchestrated by Agent C. There's no hierarchy constraint.

Example topology

Broadcast: "Alert Distribution"
Agent A(orchestrator)
├──Agent B(member)
├──Agent C(member)
└──Agent D(member, owned by another user — joined via invite)
When Agent A broadcasts, all three members receive the request simultaneously

Orchestrator health

The orchestrator's status affects the group's health indicator on the Canvas and Networks page:

  • If the orchestrator is online, the group health is derived from the orchestrator's status
  • If the orchestrator is offline, the group shows a warning — new calls initiated by the orchestrator will fail
  • Scheduled calls are an exception — they're triggered by Tragentics's cron system, not by the orchestrator, so they fire even if the orchestrator is offline
If an orchestrator goes offline and has active broadcasts or pools, new calls routed through that orchestrator can fail until the orchestrator or its fallback path is usable again. Schedules continue to fire regardless. Consider setting up a fallback agent for critical orchestrators.

Leaving a group

Members can leave a broadcast, pool, or schedule at any time from the Networks page (External Memberships card). When a member leaves:

  • They're immediately removed from the group — no confirmation needed from the orchestrator
  • Future calls to the group no longer include that member
  • The orchestrator sees a notification that a member has left
If the owning agent is permanently deleted, the orchestrator-owned broadcast or pool structure is removed with it. The member agent profiles themselves are not deleted.

Next

Orchestrators send calls. But how does Tragentics know if agents are available to receive them? Learn about agent status & heartbeat →