Vigil

Vigil — the autonomous meta-agent that plans, coordinates, and adapts across a dynamic fleet of AI agents.

Comment

Inspiration

AI agents are becoming increasingly capable, but once multiple agents start working together, the problem quickly stops being just "how good is the model?" and becomes "how do we reliably coordinate, observe, control, and reuse these agents?"

Most current agent applications are built as isolated systems. Developers often have to hardcode which agent runs, manually wire tools together, and debug failures through scattered logs. Once an agent calls tools, invokes other agents, retries, or changes its plan, understanding what actually happened becomes difficult.

That inspired Vigil: a developer platform and autonomous meta-agent for coordinating a dynamic ecosystem of AI agents.

The simplest way to describe it is:

npm + Postman + Chrome DevTools for AI agents — with an intelligent orchestration layer on top.

Instead of making developers build every multi-agent workflow manually, Vigil aims to understand an objective, determine which capabilities are required, discover suitable agents from its registry, coordinate their execution, observe the results, and adapt when the original plan is no longer sufficient.

What it does

Vigil separates the system into two ideas: specialized agents and the Vigil meta-agent.

Specialized agents are replaceable workers. They may perform code analysis, document processing, research, finance, database operations, or any other capability registered with the platform.

Vigil itself acts as the supervisor.

A typical orchestration looks like:

User objective
      ↓
Vigil interprets the goal
      ↓
Required capabilities are identified
      ↓
Registered agents are discovered
      ↓
Vigil builds an execution graph
      ↓
Agents execute asynchronously
      ↓
Outputs and events are observed
      ↓
Vigil evaluates the overall outcome
      ↓
Continue / Replan / Complete / Fail

The important architectural decision is that the LLM does not get unrestricted control over the system.

AI reasoning determines what capabilities are required, while Vigil's deterministic runtime decides which actual registered agents may satisfy those capabilities.

This combines flexible AI reasoning with predictable infrastructure.

Vigil currently supports:

  • capability-driven planning
  • dynamic agent resolution from a registry
  • multi-agent execution
  • dependency-aware execution graphs
  • asynchronous execution using job queues
  • persistent orchestration state and memory
  • live execution events and traces
  • tool-call observability
  • token, latency, and estimated cost tracking
  • runtime tool permissions
  • deterministic evaluation
  • replanning
  • cross-iteration result reuse
  • recovery of interrupted orchestrations
  • parent-level orchestration results

How we built it

Vigil is built as a TypeScript-based full-stack system.

The frontend uses Next.js, React, Tailwind CSS, and shadcn/ui.

The API and agent runtime use Node.js, Express, and TypeScript.

PostgreSQL is the durable source of truth for agents, runs, orchestration graphs, execution events, results, and persistent orchestration memory. Prisma provides the database access layer and migrations.

Agent execution is asynchronous. Vigil creates execution jobs and places them into BullMQ, while dedicated workers consume those jobs. Redis is also used for real-time event delivery between processes.

The frontend receives live execution updates through Server-Sent Events (SSE) while PostgreSQL remains the authoritative persisted state.

For reasoning, Vigil uses Gemini. The planner receives a goal and Vigil's canonical capability vocabulary, then determines which capabilities are required. The output is validated before the platform resolves real agents from the registry.

A simplified architecture is:

Next.js UI
    ↓
Vigil API
    ↓
Vigil Meta-Agent
 ┌───────────────┐
 │ Plan          │
 │ Observe       │
 │ Evaluate      │
 │ Replan        │
 └───────────────┘
    ↓
Agent Registry
    ↓
Execution Scheduler
    ↓
BullMQ / Redis
    ↓
Agent Workers
    ↓
Tools + LLMs
    ↓
PostgreSQL
    ↓
Traces / Memory / Results

We deliberately designed the system so that infrastructure such as scheduling, permissions, tracing, recovery, and persistence remains deterministic even when AI reasoning is involved.

Challenges we faced

One of the hardest problems was handling concurrent agent execution.

Multiple agents may finish at almost the same time and attempt to update the same orchestration memory. A naive implementation could cause one result to overwrite another. We addressed this using optimistic concurrency with a versioned orchestration state and compare-and-swap style updates.

Another challenge was deciding when an orchestration is actually finished.

An empty queue does not necessarily mean the user's goal has been satisfied. Vigil therefore separates execution from evaluation. Once an iteration settles, the system evaluates which capabilities were successfully satisfied, whether execution failed, and whether another plan is necessary.

Replanning introduced another problem: repeating completed work.

We added iteration-aware memory and result reuse so that a later plan can reuse successful outputs from previous iterations instead of blindly executing the same work again.

External AI providers also introduced reliability issues such as quota limits, transient failures, and model availability. We added retry behavior, timeout boundaries, and deterministic failure handling so that provider failures do not cause uncontrolled orchestration loops.

Finally, we had to think carefully about security. An AI agent should not be able to execute every available tool merely because it requests one. Vigil therefore introduces a runtime permission boundary where tools are mapped to required permissions and unauthorized calls are blocked before the underlying tool executes.

What we learned

Building Vigil changed how we think about agent systems.

The difficult part of a serious agent platform is not simply calling an LLM. The interesting engineering appears around it: state machines, distributed execution, job queues, persistence, concurrency, observability, recovery, permissions, capability discovery, and deciding which decisions should belong to an AI model versus deterministic software.

We also learned technologies that were new to us while building the system, including PostgreSQL relational modelling, Prisma migrations, Redis, BullMQ, SSE, optimistic concurrency, and durable execution state.

A particularly important lesson was that AI reasoning works better when it is given clear boundaries.

In Vigil, Gemini reasons about the problem, but the platform verifies capability IDs, resolves actual registered agents, controls tool access, persists state, and manages execution deterministically.

That separation makes the system easier to debug and significantly safer to extend.

What's next

The long-term vision is for Vigil to become an open infrastructure layer for AI agents.

Developers should eventually be able to publish agents with standardized capability, input, output, tool, and permission metadata. Other developers could discover those agents, test them in a playground, invoke them directly through a Vigil SDK, or allow Vigil's meta-agent to discover them automatically while solving larger objectives.

Our next steps include:

  • making orchestration inputs fully domain-agnostic instead of tied to any specific demonstration agent
  • dynamically resolving missing inputs from agent schemas
  • deeper result-aware reasoning by the Vigil meta-agent
  • smarter agent selection using quality, latency, cost, permissions, and historical reliability
  • Google Agent Development Kit integration
  • Google Cloud deployment
  • MCP and A2A interoperability
  • developer SDK and API keys
  • external agent publishing and versioning
  • agent evaluation and reputation
  • workflow replay and comparison
  • human approval nodes for sensitive actions

Our goal is for Vigil to evolve from a system that merely runs agents into one that can intelligently manage an open-ended fleet of agents while remaining observable, recoverable, and controllable.

Built With

Share this project:

Updates

Submission history