How AIgency actually works.
From your objective to local execution: the planner, task graph, scheduler, agent adapters and workspaces that make up AgentDock Pro's orchestration system.
The full pipeline
Every layer below is real: this is the same path a task takes from the moment you describe an objective to the moment a result comes back.
Claude Code
Codex
AntigravityPlanner
Turns a stated objective into an ordered set of tasks.
The planner is the entry point for every AIgency workflow. You describe an objective in plain language — a feature, a refactor, a fix that spans several files — and the planner breaks it into discrete, ordered tasks.
Each task is scoped narrowly enough for a single agent session to complete, and carries the context it needs from the original objective. Tasks that depend on the output of another task are marked as such, rather than assumed to run in isolation.
Task graph
Tasks and their dependencies, tracked as a graph rather than a flat list.
Once planned, tasks are held in a graph: nodes are tasks, edges are dependencies. This is what lets independent work run in parallel — a login UI task and a backend API task can proceed at the same time if neither blocks the other — while dependent tasks, like integration tests, wait for their prerequisites to complete.
The graph is also what AIgency shows you: which tasks are ready, which are blocked, and why.
Scheduler / routing
Decides what runs now, and which agent runs it.
The scheduler watches the task graph for work that's ready to run — its dependencies satisfied — and routes each task to an agent capable of handling it, based on that agent's profile.
Routing accounts for concurrency limits and provider limits, queuing work rather than firing every ready task at once.
Agent profiles & adapters
Capabilities, permissions and limits per agent, translated into each agent's native session.
Every agent AIgency can route to has a profile describing what it's good at, its default permission mode, and any limits on how it's used. An adapter layer translates a scheduled task into that agent's native session format — the same session types you already see inside AgentDock.
Workspaces / Git worktrees
Isolated working copies so parallel tasks never collide.
Each running task gets its own isolated workspace, typically backed by a Git worktree off your project's repository. This means two agents can work on different parts of the same codebase at the same time without stepping on each other's uncommitted changes.
Results are merged back deliberately, not by racing writes to a single shared checkout.
Execution lifecycle
Waiting, queued, running, done — or blocked.
A task moves through a small set of states: waiting on a dependency, queued for an available agent, running, and done. A task can also become blocked — waiting on a decision only you can make — at which point it surfaces as an issue rather than silently retrying.
Permissions & approvals
Every session carries an explicit permission mode.
Sessions AIgency starts carry the same permission model you see when running an agent directly in AgentDock — from a conservative default mode to a bypass mode for tasks you trust fully. Nothing runs with broader access than the mode you've set.
Issues & handoffs
Blocked work is surfaced back to you, not hidden.
When a task can't proceed — an ambiguous instruction, a failing check, a decision outside an agent's permission mode — AIgency raises it as an issue tied to that task, rather than guessing or stalling silently. You resolve it, and the graph continues from there.
Local-first execution & results
Everything above runs on your own machine.
Today, AIgency's planning and execution run locally on the machine running AgentDock — your code and your agent sessions don't leave your computer as part of orchestration. Completed tasks roll up into a result at the objective level, with the full task graph available underneath it.