Watchtower
An agent-native operations hub for a portfolio of customer applications — cross-app issue triage, a per-app knowledge brain, and hosted AI coding agents that turn issues into reviewable pull requests.
Problem Solved
A consultancy running many customer applications has the same problem multiplied per app: issues arrive by email, chat, and error logs; context about how each system works lives in one person's head; and every AI coding session starts from zero. Fixing a bug in app #7 means re-discovering the deploy quirks someone already learned in app #3.
Watchtower reverses this: every application registers in one hub with its issues, environments, and a curated knowledge base. Coding agents authenticate over MCP with scoped tokens and inherit everything the last session learned — and Watchtower can dispatch its own hosted agents that fix an issue end-to-end, always ending at a human-reviewed pull request.
Key Features
Command Center Triage
A cross-app dashboard surfacing critical and untriaged issues across every customer application, with severity tiers, SLA thresholds, and activity timelines — one place to answer "what needs attention right now?"
Per-App Knowledge Brain
Each application accumulates typed knowledge (runbooks, gotchas, architecture, decisions) with vector search. Resolving an issue proposes an entry automatically; agents query the brain over MCP so operational knowledge compounds instead of evaporating.
Agents as First-Class Users
A stateless MCP server exposes 25+ tools behind per-app scoped tokens. Authorization is enforced at the data layer, never from tool arguments — a token scoped to one app structurally cannot read another app's brain.
Issue → Agent → Pull Request
"Send to agent" dispatches a hosted coding agent in a scale-to-zero container job with an ephemeral scoped token. Runs stream progress, survive crashes via heartbeats and a reconciler, and always end at a PR awaiting human review — never an auto-merge.
Guardrails by Construction
Kill-switch, monthly budget caps, concurrency limits, and provider-write opt-ins gate every agent action. Secrets live in Key Vault and are never returned by any API — agents only ever see short-lived scoped tokens.
Cost & AI-Usage Monitoring
Tenant-wide Azure cost ingestion with a pivot-grid reporting cube, plus an AI-usage ledger reconciled against provider billing APIs — the cost of every agent run and chat turn is visible.
Architecture
Architecture Overview
A modular monolith: one Next.js container on Azure Container Apps presenting three faces over a shared core — the web UI, a Streamable-HTTP MCP server, and public REST/webhook APIs. Every capability is a self-registering module declaring its routes, MCP tools, jobs, and permissions; adding a feature is a new module, not core surgery.
The system is built local-first behind ports: in-memory repositories and fake providers back tests and local dev with zero cloud credentials, while Cosmos DB, Key Vault, and the real agent runner activate purely by environment config.
- App: Next.js 16 + React 19, Tailwind v4 + shadcn, single Azure Container App
- Data: Cosmos DB serverless with DiskANN vector indexes for dedup + knowledge search
- Secrets: Key Vault for retrievable secrets; salted hashes for verify-only tokens
- Agents: Claude Code / Codex in scale-to-zero Container Apps Jobs with delivery guarantees
- Delivery: self-hosted ephemeral GitHub runners; a single Bicep template IS the deploy, drift-checked daily
Key Decisions
Modular monolith over microservices
One warm replica of one container is the lowest-cost Azure architecture that still does everything — the module registry provides the seams microservices would, without the operational tax.
MCP authorization at the data layer
Tool arguments are never trusted for scoping. Every MCP tool filters by the token's resolved app scopes, covered by dedicated authorization tests — an out-of-scope app is structurally unreachable.
The human merge-gate is sacred
Agent runs end at a pull request awaiting review, never a merge. Automation earns trust by being reviewable, not by being autonomous.
Bicep is the deploy
No image-only promote path, no manual portal changes. The only way any Azure resource changes is a pipeline Bicep apply, verified by a daily drift sentinel that flags any would-be delete.
Screenshots
Interested in something similar?
We scope, design, and ship data and AI tools that solve the problems your team actually has.
Let's Talk