Knowledge → Decision → Action → Verification. Most enterprise AI stops at the answer. WorkPilot completes the work.
Five clauses, five rules, one verdict: conditionally eligible. Every rule keeps its source and clause, so the decision is traceable.
The agent stops itself. High-risk actions halt until a named person records the decision.
Six actions coordinated, five sources consulted, one human approval boundary verified against every system before reporting done.
Two policies contradict each other. Access Control §3.2 versus Incident Response §5.1. WorkPilot flags the conflict instead of guessing.
Same five skills, a harder problem. Nine steps, one escalation, three human decision points before any credential is issued.
Read-only, two hours, auto-revoke. The human narrowed the scope; 7 of 7 receipts read back before confirming.
What the agent may do alone, and where it must stop. Low risk runs automatically; conflicts escalate rather than get guessed at.
Every condition becomes a tool call with an owner and a risk tier assigned at planning time, not bolted on at the end.
From plain language to structured intent. "Three weeks" becomes 21 days; the employee record supplies the rest.
Six systems over MCP, each publishing named tools. The agent can only call what is listed.
An immutable execution log. 21 tool calls and 3 human decisions this session, each naming the system, the tool and the outcome.
12 policy documents across 6 knowledge bases, owned by the teams that write them and indexed for the agent.
Every request, with what was decided and who approved it across People Ops, Engineering, Procurement and Finance.

WorkPilot

The Great Agent Hackathon · Track 2 : Platform Agent Skills & Knowledge

Inspiration

While researching how employees actually deal with company policy, we kept running into the same quiet problem: people don't ask. Not because they don't have questions, but because reaching out to HR feels like friction, discomfort, a busy schedule, or just the effort of it. Policies themselves don't help: they're long, scattered across documents, and hard to remember, and we found that even HR and managers don't always recall the exact clause that applies. And even when someone does get an answer, part of turning that answer into action is manual, so the request still sits and waits. We wanted to close that entire loop, not just the "answer a question" part of it.

What it does

WorkPilot takes a plain-language request from an employee, reads the relevant company policies, decides what's actually eligible, and turns that decision into an executed, verified action, pausing to ask a human only at the points where a human genuinely has to decide. It doesn't stop at "here's what the policy says"; it plans the steps, calls the right systems, and reads back the result before reporting anything as done. Right now it's a frontend-only prototype: every enterprise system is simulated behind a service layer shaped like real MCP calls, so the interaction pattern is real even though the systems behind it aren't, by design, meant to be swapped for live integrations in the future.

How we built it

We structured the app around one non-negotiable rule: every write to an "enterprise system" goes through a single call surface, mockMCPService.call(system, tool, payload). On top of that sits a workflow engine that runs every request through the same eleven-stage loop, understand, retrieve knowledge, reason, decide, plan, get approval, execute, verify, report, regardless of department. Two full scenarios (international remote work, and privileged production database access) run on identical shared skills, proving the "platform" claim rather than just stating it. A headless verification harness walks both scenarios through the real service layer on every run, checking that plans, approvals, and execution counts actually match what's advertised.

Challenges we ran into

Deciding what the agent should refuse to do was the hardest design call. Our second scenario surfaced a genuine conflict: the Access Control Policy restricts production data to the owning team, while the Incident Response Policy allows elevation during an S1, both valid, both applicable. An agent that just picks one is making a governance call it has no authority to make. We rebuilt the reasoning layer to separate "high risk, but the answer is known" from "uncertain, because our own policies disagree", and made the second case escalate to a human instead of resolving itself.

We also had to prove reusability rather than claim it, which meant rewriting the first scenario twice until every scenario was pure configuration with zero scenario-specific logic in any component. And we kept the simulated integrations honest on principle, every step genuinely invokes a mock tool and reads its real response, so a failure would surface as error, not a scripted success. Our own verification harness caught two real bugs this way: a gate calling a tool that didn't exist, and a scenario claiming "6 actions coordinated" when it actually ran 7, the second one being uncomfortably close to the exact failure mode this product exists to prevent.

Accomplishments that we're proud of

The agent stops itself. Risk tiers are attached at planning time, not bolted on as a confirmation dialog, execution halts at the boundary and cannot advance without a recorded human decision.
One engine, two departments, five shared skills. Remote work and production database access share no policies, systems, or risk profile, yet run on identical skills, reuse you can watch happen live, not a slide claim.
Every decision is traceable. No bare yes/no, only verdicts like "conditionally eligible" backed by named conditions and readable clauses. We deliberately never expose model reasoning, only evidence.
Verification is a real step, not a formality, the engine reads state back from every system it wrote to before calling anything complete.
It's shaped for production already. Going live means swapping four service modules behind one call surface, no component in the presentation layer changes.

What we learned

Technically, we came into this as backend-heavy .NET/EF Core/PostgreSQL developers with mostly Angular front-end experience, so building this in React and designing an MCP-shaped service layer from scratch was new ground, and it taught us how much discipline a single call surface buys you later, even in a mocked system. Designing the escalation logic also taught us that "the agent should be helpful" and "the agent should know its limits" are two different design problems, and the second one is harder.

On the human side, the research going in mattered as much as the build. The real blocker isn't that policy is unknowable, it's that asking is uncomfortable and slow, and that discomfort compounds when even the people who wrote the policy don't fully remember it. That reframed the project for us: the goal isn't a smarter policy chatbot, it's removing the moment where someone has to work up the nerve to ask.

What's next for WorkPilot

Going forward, our priority is making the parts we currently mock real: replacing mock calls with an actual MCP client against live Freshworks systems, connecting the knowledge layer to real policy search, and moving policy reasoning from deterministic fixtures to an actual model call returning the same evidence-backed shape. We'd also add persistence (current state resets on refresh), real authentication instead of a fixed employee identity, and expand past the two scenarios into more departments, remaining true to the platform claim that a new workflow means new knowledge and tools, not a new bot.