Vigil

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

Comment

Inspiration

AI agents are becoming dramatically better at individual tasks. But once multiple agents need to work together, the hardest problem is no longer simply:

"How intelligent is the model?"

It becomes:

"How do we reliably decide which agent should act, coordinate them, observe what happened, recover from failures, and adapt when the original plan is no longer sufficient?"

Most agent applications still solve this with hardcoded workflows. Developers manually decide which agent runs next, wire tools together themselves, and debug failures through scattered logs. Once agents start calling tools, running concurrently, depending on each other, or changing their plans, the system becomes increasingly difficult to reason about.

That inspired Vigil — an autonomous meta-agent and developer infrastructure platform for coordinating a dynamic fleet of AI agents.

A simple analogy is:

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

Instead of requiring developers to manually construct every multi-agent workflow, Vigil accepts a high-level objective and uses Gemini to reason about what capabilities are required. Its deterministic runtime then discovers real agents from the registry, coordinates their execution, observes their results, evaluates progress, and replans when necessary.

The central architectural principle is:

Gemini reasons about what needs to be done. Vigil deterministically decides which registered agent is allowed to do it.

That separation lets us combine flexible AI reasoning with controllable infrastructure.

What it does

Vigil separates a multi-agent system into two layers:

Specialist agents perform domain-specific tasks such as code review, security analysis, web research, document processing, or external API operations.

The Vigil meta-agent acts as the supervisor that decides how those specialists should work together.

A typical orchestration looks like:

User Objective
      ↓
Vigil Meta-Agent
      ↓
Gemini identifies required capabilities
      ↓
Vigil validates those capabilities
      ↓
Agent Registry resolves real implementations
      ↓
Dependency-aware execution plan
      ↓
Specialist agents execute asynchronously
      ↓
Vigil observes results + traces
      ↓
Gemini + runtime evaluate progress
      ↓
Complete / Replan / Fail

A crucial distinction is that the LLM never receives unrestricted authority to invent or directly execute arbitrary agents.

For example, Gemini may determine that a task requires:

web-research
security-review
code-review

Vigil then resolves those capability IDs against agents that are actually registered in the platform.

This makes orchestration agentic without making infrastructure unpredictable.

Vigil currently supports:

  • capability-driven planning
  • dynamic agent discovery and resolution
  • dependency-aware multi-agent execution
  • asynchronous execution through workers
  • persistent orchestration memory
  • result-aware evaluation
  • autonomous replanning
  • cross-iteration result reuse
  • live execution traces
  • tool-call observability
  • token, latency, and estimated-cost metrics
  • runtime tool permissions
  • recovery of interrupted orchestrations
  • native Vigil agents
  • Google ADK-powered agents
  • remotely hosted developer agents
  • a JavaScript/TypeScript SDK

One example is the Google Search Researcher, a specialist agent built using Google Agent Development Kit (ADK). Vigil decides when web research is needed and selects the registered researcher; ADK powers the specialist agent that performs the research.

In other words:

Vigil decides what the team should do. Google ADK helps an individual team member do its job.

How we built it

Vigil is built as a full-stack TypeScript system with Google AI at the center of its agentic reasoning layer.

AI and agent layer

We use Gemini 3.6 Flash through the Google GenAI SDK for meta-agent reasoning.

Gemini receives:

  • the user's objective
  • Vigil's canonical capability vocabulary
  • relevant execution state
  • previous results
  • orchestration memory

It then determines what capabilities are required or whether the current result is sufficient.

Importantly, Gemini does not directly choose arbitrary agent IDs.

Its capability output is validated, and Vigil's deterministic runtime resolves each capability against the actual agent registry.

For specialist agents, Vigil supports multiple execution runtimes. One of those runtimes is Google Agent Development Kit (ADK).

Our Google Search Researcher uses ADK together with Google Search to provide the web-research and information-retrieval capabilities.

This means ADK integrates inside Vigil rather than replacing Vigil's orchestration layer.

Runtime architecture

The frontend is built with:

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • shadcn/ui

The API and runtime use:

  • Node.js
  • Express
  • TypeScript

PostgreSQL stores agents, runs, orchestration steps, traces, results, API keys, and persistent orchestration memory.

Prisma provides the database access and migration layer.

Long-running agent execution is asynchronous:

Vigil API
   ↓
BullMQ
   ↓
Redis
   ↓
Worker
   ↓
Selected Agent Runtime

Dedicated workers execute agent jobs outside the request lifecycle.

Redis also provides Pub/Sub for live execution events, while the browser receives those events through Server-Sent Events (SSE).

PostgreSQL remains the durable source of truth.

Google Cloud deployment

Vigil's backend infrastructure is deployed using Google Cloud Run.

Next.js Frontend
        ↓
Vigil API — Google Cloud Run
        ↓
Meta-Agent
        ↓
Agent Registry
        ↓
BullMQ / Redis
        ↓
Vigil Worker — Google Cloud Run
        ↓
Native / Google ADK / Remote Agents
        ↓
Gemini + Tools

This separation allows API requests and long-running agent workloads to scale independently.

Challenges we faced

One of the most difficult problems was concurrent agent execution.

Two agents may complete almost simultaneously and both attempt to update orchestration memory. A naive last-write-wins approach could silently discard one result.

We solved this using versioned orchestration state and optimistic concurrency, allowing updates to behave similarly to compare-and-swap operations.

Another challenge was determining when an orchestration is actually finished.

An empty job queue does not necessarily mean the user's objective has been achieved.

Vigil therefore separates execution from evaluation.

After an execution iteration settles, Vigil evaluates:

  • which required capabilities were satisfied
  • which steps failed
  • what useful results already exist
  • whether the user's broader objective has been achieved

If not, it can construct another plan.

That led to another problem: replanning could repeatedly execute work that had already succeeded.

We therefore added cross-iteration result reuse.

If web-research succeeded in iteration one and the next plan still depends on that information, Vigil can reuse the previous result rather than invoking the researcher again.

This reduces latency, external calls, and token usage.

We also encountered the realities of external AI infrastructure: quota limits, temporary provider failures, timeouts, and unavailable models.

We added bounded retries, deterministic failure states, execution timeouts, persisted state, and recovery logic so that a provider failure cannot cause an uncontrolled orchestration loop.

Finally, tool security required a clear boundary.

An LLM should not gain access to a tool merely because it asks for it.

Agents therefore declare permissions such as:

repository:read
pull_requests:read
web.read

Vigil applies a default-deny permission layer before supported tools can execute.

What we learned

The biggest lesson from building Vigil was that serious agent engineering is much more than calling an LLM.

The difficult and interesting problems appear around the model:

  • distributed execution
  • state machines
  • queues
  • concurrency
  • persistence
  • retries
  • observability
  • recovery
  • permissions
  • capability discovery
  • evaluation
  • deciding which decisions should belong to AI versus deterministic software

Google's agent tooling also reinforced an architectural lesson for us:

not every intelligent component should be responsible for the whole system.

Google ADK works extremely well as the runtime for a capable specialist agent.

Vigil operates one abstraction level above it.

The meta-agent determines what expertise is needed, the deterministic registry resolves an implementation, and ADK can then give that specialist its own model, tools, and execution behavior.

We found that AI reasoning becomes substantially easier to control when it operates inside explicit infrastructure boundaries.

Gemini can reason flexibly about the objective, while Vigil still verifies capability IDs, controls tool permissions, resolves real agents, persists state, schedules work, and records every execution.

That combination gives us both autonomy and inspectability.

What's next

Our long-term goal is for Vigil to become an open infrastructure layer for interoperable AI agents.

Developers should be able to publish an agent with standardized:

  • capabilities
  • input and output schemas
  • tools
  • permissions
  • runtime information
  • versions

Other developers could then discover that agent, test it interactively, invoke it through the Vigil SDK, or allow the Vigil meta-agent to discover it automatically while solving a larger objective.

The next areas we want to expand are:

  • quality-, latency-, reliability-, and cost-aware agent selection
  • richer Gemini-based result evaluation
  • deeper Google ADK integrations
  • more ADK-powered specialist agents
  • MCP interoperability
  • Agent-to-Agent (A2A) interoperability
  • agent versioning and publishing
  • agent evaluation and reputation
  • workflow replay and comparison
  • human approval nodes for sensitive actions
  • policy-aware permission controls
  • larger distributed agent fleets on Google Cloud

The eventual vision is not simply a platform that can run AI agents.

It is an intelligent control plane that can:

discover, coordinate, observe, evaluate, and adapt across an open-ended ecosystem of agents — while keeping execution grounded, recoverable, and controllable.

For us, that is the infrastructure required for agent systems to move from impressive demos to dependable software.

Built With

Share this project:

Updates

Submission history