Managed Agent Runs: Autonomous Agents That Work on Your Architecture While You Sleep

Two weeks ago we launched Agent Hub with conformance guardrails — rules that tell AI agents what they can and can't do. That was the defensive layer. Today we're adding the offensive one.

Managed Agent Runs let you dispatch autonomous AI agents directly from Archyl. Give them a task, connect them to your tools, set a schedule, and let them work. They clone your repository, read your architecture, call external services, and report back with everything they did — every tool call, every decision, every token spent.

This isn't "chat with your architecture." This is an agent that does real work, autonomously, on your codebase.

Why Managed Runs?

The pattern we kept seeing was this: teams would set up conformance rules, generate their CLAUDE.md file, and then manually run agents in their terminal. Copy the context, paste it into Claude Code, run the task, check the output. Every single time.

The missing piece was automation. You shouldn't have to babysit an agent that's doing a routine task. Check for stale dependencies every Monday morning? That should be a schedule. Review open PRs against architectural rules after every merge? That should be automatic. Generate a weekly architecture drift report? Set it and forget it.

Managed runs close this loop. Define the task, pick a schedule, and Archyl handles the rest — cloning, context injection, execution, and monitoring.

Anatomy of a Run

Every managed run follows the same lifecycle:

  1. Clone — The agent clones your project's repository into an isolated workspace. Fresh copy, no contamination from previous runs.

  2. Context injection — Before the agent writes a single line of code, it receives your full architectural context: C4 model, ADRs, conformance rules, technology stack, API contracts. The same get_agent_context data that powers the guardrails, injected automatically.

  3. Execution — The agent works through your task. It can read files, write code, call external tools, and make decisions. Each action is logged as an event in a real-time feed.

  4. Reporting — When the run completes (or hits the iteration limit), you get a full trace: every tool call with its input and output, status badges, token counts, elapsed time.

The run detail page shows everything. Tool calls are expandable cards with syntax-highlighted JSON. Each card shows which connector the tool came from — "github" for GitHub API calls, "archyl" for architecture queries, "linear" for issue tracking. You can trace exactly what the agent did and why.

Connectors: Plug In Any MCP Service

Here's where it gets interesting. Managed runs don't just talk to Archyl. They can talk to anything that speaks MCP (Model Context Protocol).

Connectors let you attach external services to your agent runs. Out of the box, we support:

  • GitHub — Read PRs, check CI status, list issues, review code
  • GitLab — Same capabilities for GitLab-hosted projects
  • Linear — Read and update issues, check sprint progress
  • Slack — Post messages, read channels, notify teams
  • Any MCP server — If it exposes MCP tools, you can connect it

Setting up a connector takes thirty seconds. Give it a name, paste the server URL, add authentication headers if needed, and Archyl will probe the server to discover available tools. You'll see every tool the connector exposes before you save.

When you create a run or schedule, you pick which connectors to attach. The agent gets access to all tools from all attached connectors, namespaced by connector name. A GitHub tool appears as github__list_pull_requests. A Linear tool appears as linear__get_issue. No collisions, no ambiguity.

This namespacing matters. When you look at a run's event feed, every tool call shows its source. You can instantly tell whether the agent was querying your architecture model, reading a GitHub PR, or posting to Slack. Full visibility into what the agent touched and where.

Schedules: Cron-Based Automation

Some tasks shouldn't wait for a human to press "Run." Schedules let you define recurring agent runs with standard cron expressions.

A few examples of what teams are already doing:

Weekly architecture review — Every Monday at 9am, an agent checks the codebase for architectural drift. It compares the actual code structure against the C4 model, flags new dependencies that aren't documented, and identifies components that have grown beyond their intended scope.

PR conformance check — After every merge to main, an agent reviews the diff against conformance rules. It catches the patterns that slipped through CI — not syntax errors, but architectural violations that only make sense in the context of the full system.

Dependency audit — Every Wednesday, an agent scans the dependency tree for known vulnerabilities, deprecated packages, and version mismatches across services. It creates a summary with severity ratings and suggested updates.

Documentation sync — Every Friday afternoon, an agent compares the current codebase against the project documentation. Missing endpoints, outdated descriptions, new services without docs — it flags them all.

Each schedule shows its cron expression, next run time, last run time, and active/paused status. You can pause a schedule without deleting it, trigger it manually outside its normal cadence, or edit the task text and timing at any time.

The Run Detail Page

We spent a lot of time on the monitoring experience because visibility is everything when you're letting an agent work autonomously.

The run detail page gives you:

  • Status at a glance — Running, completed, failed, or cancelled. Color-coded badge, visible immediately.
  • Token usage — Input and output tokens, so you can track costs per run.
  • Elapsed time — How long the agent worked, updated in real-time during execution.
  • Run ID — For traceability and debugging.
  • Live event feed — Every action the agent takes appears as an expandable card. Tool calls show the connector source, tool name, input parameters, and output. Messages show the agent's reasoning. Errors are highlighted.

The feed is designed for scanning. Collapsed rows show the event type and a one-line summary. Hover to see the connector badge and expand for full details. When something goes wrong, you don't dig through logs — you scroll through a structured timeline of exactly what happened.

Architecture-Aware by Default

Every managed run gets automatic access to your Archyl project's MCP server. This means the agent can:

  • Query the C4 model to understand system boundaries
  • Read ADRs to understand past decisions
  • Check conformance rules to know what patterns to follow
  • Browse API contracts to understand service interfaces
  • Look up technology assignments to pick the right tools

This isn't an optional integration. It's the foundation. The agent doesn't start from zero — it starts from your architecture. When it needs to create a new service, it knows which container it belongs in. When it writes code, it knows which patterns are enforced. When it adds a dependency, it knows which technologies are approved.

Combined with external connectors, this creates agents that are both architecturally aware and operationally capable. They know your system and they can interact with your tools.

Getting Started

Managed Agent Runs are available now in Agent Hub for Business and Scale plans.

  1. Create a connector — Go to Agent Hub → Connectors. Add your GitHub, Linear, or any MCP-compatible service.
  2. Start a run — Go to Runs → New Run. Write your task, attach connectors, and launch.
  3. Set up a schedule — Go to Schedules → New Schedule. Pick a cron expression, attach connectors, and let it run.

The agents are ready. Your architecture is the context. Your tools are the connectors. Now put them to work.