External Agent Management: Run Anywhere, Control from One Place

Most AI agent platforms force a choice: use our framework, or you are on your own. That assumption breaks down the moment you have a CrewAI crew generating content, an n8n workflow processing invoices, a Make scenario handling customer onboarding, and a custom Python agent running compliance checks. Each one works well independently. None of them know about the others. Nobody has a unified view of what ran, when, what it cost, or whether it should have run at all.

External Agent Management flips the model. Instead of requiring agents to be built inside a platform, it lets agents execute wherever they already run — CrewAI, n8n, Make, LangChain, AWS Lambda, GCP Cloud Run, or any HTTP endpoint — while Dobby provides the management layer on top: scheduling, triggering, approval gates, cost tracking, and an immutable audit trail.

The Problem with Scattered Agents

When agents are scattered across platforms, three problems compound. First, scheduling becomes fragmented. Your CrewAI crew runs on a cron job inside your infrastructure. Your n8n workflow triggers on a webhook. Your Make scenario runs on its own schedule. Nobody sees the full picture of what fires when, and schedule collisions — two agents hitting the same API at the same time — are invisible until something breaks.

Second, there is no approval layer. An agent that generates customer-facing content or modifies production data should not run unsupervised. But adding human-in-the-loop approval to each platform separately means building the same approval UI three times, in three different systems, with three different notification channels.

Third, cost attribution is impossible. When agents across five platforms all hit OpenAI, the invoice shows one number. You cannot answer basic questions: which agent costs the most? Which one has the worst cost-per-task ratio? Should you move the summarization agent from GPT-4o to Claude Haiku to cut costs by 80 percent?

How External Agent Management Works

The concept is straightforward. Register your agent with Dobby by providing its HTTP endpoint, authentication method, and a description of what it does. From that point, Dobby becomes the orchestration layer — it decides when the agent runs, enforces governance checks before triggering it, sends a webhook POST to kick off execution, and tracks the result. The agent itself does not change. It receives a webhook, does its work, and optionally calls back with a status update.

Registration takes about 30 seconds. You provide the agent name, framework (CrewAI, n8n, Make, LangChain, or custom), the endpoint URL, and an optional auth config. Dobby supports three auth methods: API key (Bearer token), custom headers (for agents behind API gateways), and no auth for public endpoints.

{
  "name": "Content Generation Crew",
  "framework": "crewai",
  "endpoint_url": "https://app.crewai.com/api/v1/crews/kickoff",
  "auth_config": {
    "method": "api_key",
    "header": "Authorization",
    "prefix": "Bearer",
    "key": "sk-crew-xxx"
  }
}

Scheduling Without the Overhead

Once registered, you can schedule the agent with cron expressions or presets — hourly, daily, every three days, or weekly. Dobby's scheduler runs a governance preflight before every trigger: it checks the organization kill-switch, validates budget limits, and verifies that the agent has not been paused or blocked. If any check fails, the trigger is skipped and the reason is logged. No silent failures.

Manual triggers work too. Click a button in the dashboard, or call the trigger API endpoint. Both paths go through the same governance preflight, so a manually triggered agent gets the same policy enforcement as a scheduled one. The trigger payload is customizable — you can pass parameters like topic, language, or target audience that the agent uses to customize its execution.

The Webhook Trigger Pattern

When Dobby triggers an external agent, it sends a POST request with a structured payload. The payload includes a trigger ID for tracking, the agent and task IDs for correlation, a callback URL for status updates, and any custom payload you configured. The agent's job is simple: receive the webhook, do the work, and POST a completion event back to the callback URL.

// Dobby sends to your agent
{
  "trigger_id": "trig_abc123",
  "agent_id": "ext_def456",
  "trigger_type": "scheduled",
  "payload": { "topic": "AI governance", "word_count": 1500 },
  "callback_url": "https://dobby-ai.com/api/v1/external-agents/ext_def456/events"
}

// Your agent sends back
{
  "event_type": "run.completed",
  "data": {
    "status": "completed",
    "result_summary": "Blog post written successfully",
    "cost_usd": 0.12,
    "duration_seconds": 45
  }
}

The callback is optional. If your agent does not call back, Dobby marks the trigger as sent and moves on. You can still track success or failure through the trigger history in the dashboard. But when agents do call back, Dobby records the cost, duration, and result summary — building a complete cost and performance profile over time.

Human-in-the-Loop for External Agents

Some agents should not run without approval. A content agent that publishes to your blog, a data agent that modifies production records, a compliance agent that files regulatory reports — these need a human to say yes before execution. External Agent Management plugs directly into Dobby's approval system. Configure an agent to require approval, and every trigger — scheduled or manual — creates a pending approval instead of firing immediately.

Approvals show up in the dashboard and optionally in Slack with interactive buttons. The approver sees what the agent will do, which schedule triggered it, and what payload it will receive. One click to approve, one click to reject. Approved triggers fire immediately. Rejected triggers are logged with a reason. The same approval chain works whether the agent is a CrewAI crew, an n8n workflow, or a custom Lambda function.

Trigger History and Audit Trail

Every trigger attempt is logged in an immutable audit trail with its full lifecycle: pending, sent, completed, or failed. You can see exactly when each agent ran, how long it took, what it cost, and whether it succeeded. Failed triggers show the error response. Retrying a failed trigger is one click — Dobby resends the same payload to the same endpoint and tracks the retry as a linked event.

The trigger history rolls up into per-agent statistics: total runs, success rate, average duration, total cost. These stats appear on the agent cards in the dashboard, so you can compare performance across your entire agent fleet at a glance. When a scheduled agent's success rate drops below a threshold, you know immediately — not after the next quarterly review.

Supported Platforms

Any agent with an HTTP endpoint works. The trigger is a standard POST webhook, which means virtually every automation platform, serverless function, and agent framework is compatible without modification. Teams have connected CrewAI crews, n8n workflows, Make scenarios, Zapier zaps, LangServe deployments, GCP Cloud Run services, and AWS Lambda functions. If it can receive an HTTP POST and return a response, Dobby can manage it.

Getting Started

Start with one agent. Pick the external agent that runs most frequently or costs the most — that is where management overhead compounds fastest. Register it in Dobby, set up a schedule, and watch the trigger history build. Within a week you will have a baseline: average duration, cost per run, success rate. Then add a second agent. Then set a budget. Then add an approval gate for the one that touches production data. Each step is incremental and each one gives you data you did not have before.

The goal is not to replace your agent platforms. It is to manage them. Your CrewAI crews keep running on CrewAI. Your n8n workflows keep running on n8n. Dobby sits above them all, providing the scheduling, governance, and visibility layer that no individual platform can provide on its own.