Agent orchestration

How Method’s AI Agents run inside the platform, how the platform drives them, and how you extend them with your own Agents, harnesses, and models.


Overview

Method’s platform is agent-driven. Behind most workflows is an AI Agent that gathers context, reasons about it, and acts. Method runs and orchestrates these Agents for you: as you and the platform’s own AI workflows do work, that activity drives Agents to spin up, act, and wind down. Violet is Method’s AI and the harness that runs those Agents inside the platform.

The following ideas guide how Method orchestrates Agents:

  • Platform-driven: The platform’s own workflows produce the events that put Agents to work. You do not launch or babysit them.
  • Integrated by default, open at the edges: Method’s shipped Agents and the custom Agents you build run through the same flow. You can also reach in from your own harness and bring your own model.
  • Sandboxed and governed: Every Agent runs in a secure sandbox with a curated tool set, under the same guardrails that govern the rest of the platform.

The rest of this page walks through that architecture: how the platform drives Agents, what an Agent can do in its sandbox, how it acts on the platform under the same controls as people, how models are served, and how you extend the system with your own Agents, harness, and models.

Diagram showing shipped and user-configured Agents connecting through the Agent Message Bus to the Cloud Agent Manager, Violet Agent Harness, model infrastructure, Tool Provider boundary, Rules of Engagement, and orchestration platform
How Method orchestrates shipped and user-configured Agents

How the platform drives Agents

You rarely start an Agent by hand. The platform drives Agents in response to what is happening inside it.

As you and the platform’s AI workflows do work, that activity publishes events to the Agent Message Bus. Method listens to the bus and, in response, spins up Agents, routes messages to them, and spins them down when their work is done. The key idea is not any single trigger. It is that the platform itself continuously produces the events that put Agents to work, and you see the results throughout the product.

Method runs each Agent in the Cloud Agent Manager, Method’s secure, managed compute. You never provision or scale it: the Cloud Agent Manager launches an instance of the Violet Agent Harness for each running Agent and tears it down when the work is done. Violet is the harness itself, the runtime loop that holds an Agent’s context, decides which tools to call, and turns model output into real actions. Because Violet runs inside Method, each Agent is fully integrated with the platform, reading from the Ontology and writing results back where the rest of the platform can use them.

The Agents driven this way include Method’s shipped Agents, the out-of-the-box Agents behind features like Overwatch, Targeting, and Operator, along with any custom Agents you add.

Shipped Agents and custom Agents

Method ships Agents out of the box that carry out its workflows. You already rely on them across the product, doing the reasoning behind features you use every day.

You are not limited to those. Method includes an Agent builder, so you can create your own Agents and insert them into the platform’s workflows. Wherever the platform runs an Agent, you can generally supply your own instead: your own Overwatch Agent, your own Targeting Agent, Agents tied to a type of Object that you open in Explorer, and more. You will find these insertion points as you move through the platform, product by product, and each product’s own documentation shows where and how to plug your Agents in.

Custom Agents are first-class. They run through the same platform-driven flow, the same Cloud Agent Manager and Violet Agent Harness, with the same access to platform Tools and data as Method’s shipped Agents.

The Agent sandbox

Every Agent runs in a sandbox that behaves like a small, isolated computer, giving it a private workspace without control of a real machine. Inside the sandbox, Agents get a built-in tool set:

  • A working file system: Agents create, read, and write files and directories in a workspace that persists across the run, so an Agent can build up and revisit its own work.
  • Standard command-line tools: common utilities such as jq, grep, awk, and sed for slicing and transforming data.
  • Code execution: Agents can run Python for anything the built-in tools do not cover.

Agents never get a raw terminal or arbitrary command access. The sandbox gives them a curated, safe equivalent.

Tools, permissions, and Rules of Engagement

The sandbox is where an Agent works on its own. To act on your environment and the rest of the platform, an Agent uses MCP tools, and that access is permissioned: each Agent gets only the tools it is allowed to use, covering security tool execution, data interrogation, an AI skills catalogue, and any customer-provided MCPs you register.

The tools that have real effects on your environment are the same tools the platform runs for everyone. They execute through the Method Orchestration Platform, whose Workflow Orchestrator carries out the workflow and whose Data Search APIs answer questions against your data, and they run under the same Deterministic Rules of Engagement and Policies that govern human operators. Because Agents act through the same permissioned Tools, the same orchestration, and the same Rules of Engagement as people, they use the platform the same way and under the same controls as humans, and every action stays in-bounds and auditable.

Models and the Method AI Gateway

Every model call, whether from Method’s Agents or from your own, passes through the Method AI Gateway, which applies spend and concurrency controls so Agent activity stays within bounds.

Behind the gateway, the Model Configuration Service decides which model serves a request. Method does not lock you to a single model. You can use Method-configured inference, bring your own model, or run on-premises inference: point Method at the model you want, and as long as Method can reach it, Method can use it. Model choice is yours at a fine grain. You select the model per Agent and per workflow, and you can change the models Method uses from inside the platform whenever you like.

Bring your own harness

You can also drive Method from your own harness, such as Claude Code, Codex, or one you build yourself. Through Violet’s MCP interface and the Method AI Gateway, your harness calls the same platform capabilities that Method’s own Agents use, including the same MCP tools that power in-platform workflows. That lets you run Method’s built-in workflows from your own environment, on your own terms.

Why this matters

This model has practical implications for how you work with Method:

  • Nothing to operate: Method runs and scales Agents for you, so there is no agent infrastructure to deploy or maintain.
  • One way to extend: Custom Agents run through the same platform-driven flow as Method’s shipped Agents, with the same access to Tools, data, and governance.
  • Open at the edges: You can bring your own model and drive the platform from your own harness, while keeping the platform’s control and auditability.

For the primitives Agents build on, see AI Agents and Tools. For how the platform is deployed and how the platform-agent split works, see System architecture and Data architecture. For the security agents that act inside target environments, see Jackal C2.