Weir | Devpost

Inspiration

Every enterprise approval tool — procurement sign-off, expense approval, access requests, contract review — treats a slow approver as an inbox-design problem. Better notifications, smarter routing, a nicer dashboard. None of that addresses the actual failure mode: an approver is a finite-capacity resource with a measurable decision-latency curve, functionally identical to a GPU with a finite KV-cache serving inference requests. When an approver is oversubscribed, requests don't fail loudly — they silently pile up, latency creeps up for everyone waiting behind them, and nobody has a signal that it's happening until someone escalates in frustration. Nobody had applied real capacity-governance thinking — the discipline used to manage overloaded infrastructure — to the equivalent problem in human approval chains. So we did.

What it does

Weir is an admission-control layer that sits in front of any approval-driven workflow and governs load the way a capacity-aware proxy governs traffic to a constrained backend.

Live pressure signal — each approver's decision latency is classified as Normal, Elevated, or Critical using consecutive-sample thresholds and hysteresis, so a single slow day doesn't trigger overreaction.
Bounded queueing — incoming requests get a tracked deadline instead of piling into an inbox indefinitely.
Governance Agent — once an approver is sustained in Critical, an LLM agent reasons over the full queue and proposes what to do: delegate, auto-approve under a value threshold, escalate to a human, or hold.
Deterministic guardrail — every proposal is validated by a separate, plain-Python policy engine checking risk tier, value threshold, and an hourly auto-approval rate limit. The agent never writes to the ledger or mutates state directly — it only proposes.
Full auditability — every decision, including rejected proposals, is logged with a human-readable reason, so "agent proposed X, policy said no" is a first-class, visible event.

How we built it

The backend is a FastAPI service with a plain, readable Python state machine for pressure evaluation and policy validation — deliberately not a rules DSL or a black box, since explainability is the actual product. Live pressure and queue state live in an in-process store shaped to swap into Redis later; decisions land in a durable, queryable ledger. The Governance Agent runs in two modes: an offline deterministic stand-in for fast iteration, and a live mode where Claude reasons over a small tool set (read pressure/queue/policy state, propose delegate/auto-approve/escalate/hold). A single-page dashboard, served directly by the API with no separate frontend build, shows live pressure per approver, queue depth with deadline countdowns, and the decision ledger with expandable agent reasoning. A simulate script drives synthetic load so pressure genuinely climbs from backlog alone — nothing in the demo is mocked.

Challenges we ran into

Keeping the agent honest was the hardest part: it would be easy to let an LLM directly approve or delegate requests, but that breaks auditability the moment something goes wrong. We had to draw a hard line — the agent only ever proposes, and a separate deterministic engine is the sole authority that commits a decision — and make sure a rejected proposal was just as visible in the ledger as an accepted one. Getting pressure to rise from live backlog (not just from resolved decision times) also took a rework, since without it the dashboard looks calm right up until it doesn't.

Accomplishments that we're proud of

A real, working FastAPI backend and dashboard — not a mockup — with pressure, queueing, delegation, and auto-approval all demonstrable end to end from a single simulated load script, plus full test coverage of the policy engine and request lifecycle.

What we learned

That the gap in enterprise approval tooling isn't UX — it's the complete absence of systems-governance thinking applied to a human-in-the-loop bottleneck, and that agentic reasoning is genuinely more trustworthy when it's constrained to proposing rather than acting.

What's next for Weir

Real connectors to procurement/ticketing systems, Redis-backed multi-replica state, a multi-signal pressure model incorporating SLA-breach history, and configurable multi-level escalation chains.