Inspiration

Recruiting is a multi-step process involving recruiters, candidates, hiring managers, interviewers, and increasingly, AI assistants. However, people and agents usually interact with separate systems. A human may use a recruiting dashboard while an agent relies on screen scraping, custom APIs, or incomplete information.

We wanted to explore what happens when a recruiting application becomes a shared workspace for both people and agents. This inspired PipelineOS: a WebMCP-powered recruiting platform where humans and agents can discover capabilities, perform structured actions, collaborate on decisions, and observe the same live workflow.

The demo uses an Indian-context recruiting dataset with candidates such as Ananya Sharma, Rohan Mehta, Kavya Iyer, and Meera Nair, making the experience feel relevant to our target users and region.

What it does

PipelineOS models the complete hiring lifecycle:

• Job requisition creation
• Candidate search and comparison
• Application submission
• Explainable candidate screening
• Interview availability and scheduling
• Interview feedback
• Offer generation and response
• Background checks
• Benefits enrollment
• Onboarding checklists
• Workflow status and activity tracking

The Recruiter Dashboard presents applications in a Kanban board across stages such as Applied, Screened, Interviewing, Offer Sent, Offer Accepted, Onboarding, and Rejected.

The important difference is that the same operations are available to both the human interface and an AI agent through WebMCP.

Why this is a strong fit for WebMCP

Recruiting has structured, multi-step actions that agents need to discover and execute reliably. Instead of asking an agent to interpret buttons or scrape a page, PipelineOS exposes named tools with typed input schemas, descriptions, permissions, and output contracts.

An agent can search candidates, read workflow status, prepare interview coordination, and stage onboarding actions using the same operation surface used by the human UI.

How it creates a better user experience

PipelineOS creates one shared source of truth:

• Human actions and agent actions update the same recruiting state.
• Candidates appear in the same Kanban board regardless of who performed the action.
• Recruiters can see agent activity in the same audit feed as human activity.
• Agents can handle repetitive research and coordination work.
• Humans remain in control of consequential decisions.
• Every operation has a structured result or error instead of an ambiguous UI interaction.

This means users do not have to copy information between an AI assistant, spreadsheets, email, and an applicant tracking system.

What people and agents can do together

Before WebMCP, an agent could potentially read a recruiting page but could not reliably discover or invoke the same application actions as a human.

With PipelineOS:

• A recruiter can ask ChatGPT to find strong backend candidates.
• ChatGPT can use the page’s WebMCP tools to search the candidate database.
• The recruiter can review the result in the same PipelineOS workspace.
• An agent can prepare an onboarding plan without applying it.
• A human can review the proposed changes, approve them, and commit them.
• The resulting state change appears in the Kanban and activity feed for everyone.

This makes it possible for agents to support hiring operations without giving them unchecked control over sensitive or irreversible actions.

How we built it

PipelineOS is built as a React and TypeScript web application with an Express server.

The WebMCP integration is implemented in src/lib/webmcp.ts. On application startup, PipelineOS registers the canonical operation registry with:

document.modelContext.registerTool({
  name,
  description,
  inputSchema,
  execute,
  annotations
});

The application registers 32 recruiting operations from one shared OPERATION_REGISTRY. The registry is also used by:

• Server-side validation
• The React UI
• WebMCP tool registration
• Documentation pages
• Capability discovery
• Approval-policy enforcement

Every WebMCP execute callback routes through the same OperationClient used by the UI. The request then passes through:

1. The canonical HTTP API
2. Actor and capability resolution
3. Input validation
4. Authorization and resource-scope checks
5. The shared OperationService
6. Domain rules and lifecycle validation
7. The repository transaction
8. The activity/audit log
9. State synchronization back to the UI

There is no separate WebMCP-only business logic path.

For sensitive workflows, PipelineOS uses a plan → approve → commit model:

plan_operation
        ↓
human approval card
        ↓
approve_operation_plan
        ↓
commit_operation_plan

Agents can stage an action, but they cannot approve their own plans. This is enforced server-side.

The application also supports:

• Native document.modelContext registration
• A navigator-based compatibility adapter
• A development registry for local testing
• Structured JSON schemas
• Actor-scoped permissions
• Idempotency and stale-state protection
• Revision-based synchronization
• Server-sent events
• A shared activity feed
• Deterministic synthetic demo data
• In-memory and Firestore persistence options

Challenges we ran into

The biggest challenge was making the human and agent interfaces genuinely share the same behavior instead of simply exposing a second API.

We had to ensure that:

• WebMCP calls and UI clicks use the same operation service.
• Operations validate and authorize inputs consistently.
• Failed mutations do not partially update state.
• Agent permissions are narrower than human permissions.
• Approval requirements are enforced by the server rather than only described in tool text.
• Activity entries do not expose private resume data, tokens, consent evidence, or sensitive identifiers.
• Multiple browser views stay synchronized after an agent call.
• Repeated requests do not create duplicate applications, interviews, offers, or onboarding records.
• The demo remains deterministic and easy to reset during judging.

Authentication and hosted access were another challenge because the live application needs to be accessible to judges while still protecting recruiter, candidate, and hiring-manager views.

Accomplishments that we're proud of

We are proud that PipelineOS is more than a WebMCP proof of concept. It is a complete recruiting workflow with a real product experience around the tools.

Our main accomplishments include:

• A complete multi-role recruiting application
• 32 shared WebMCP operations
• Native document.modelContext.registerTool integration
• One operation path for humans and agents
• A populated Indian-context demo Kanban with candidates across multiple lifecycle stages
• A shared live activity feed for human and agent actions
• Explainable, deterministic candidate scoring
• Human approval cards for consequential agent workflows
• Server-enforced agent safety rules
• Actor-scoped authorization and resource permissions
• Idempotency and atomic state changes
• Candidate, recruiter, and hiring-manager experiences
• Documentation that displays the live WebMCP operation registry
• A deterministic reset flow suitable for demos and judging

The most important accomplishment is that an agent can participate in the workflow without becoming an uncontrolled automation layer. It can help with research and preparation, while the human remains responsible for the final consequential action.

What we learned

We learned that exposing tools is only one part of building an agent-ready application. The surrounding product architecture is equally important.

We learned that:

• Tool descriptions must explain when an operation should be used and what it returns.
• Input and output schemas make agent behavior more reliable.
• Agent permissions must be enforced at the server boundary.
• Human approval should be represented as a real stateful workflow, not just a confirmation message.
• A shared audit trail is essential when humans and agents work together.
• Agents need safe read-only discovery tools before they can perform useful actions.
• The same operation must produce the same result whether it comes from a button, WebMCP, or an MCP client.
• Deterministic demo data makes an agent workflow much easier to demonstrate and evaluate.
• WebMCP is most valuable when it changes the interaction model of the application, rather than being added as a thin wrapper around an existing API.

What's next for PipelineOS

The next step is to connect PipelineOS to durable, production recruiting systems while keeping the same operation registry and WebMCP interface.

Planned improvements include:

• Greenhouse, Lever, and HRIS integrations
• Durable multi-tenant storage by default
• Production-grade authentication for recruiters, candidates, and agent connectors
• Per-organization agent capabilities and approval policies
• Candidate consent and communication workflows
• Calendar and email integrations
• More detailed fairness and compliance reporting
• Agent-assisted bottleneck and hiring-funnel analysis
• Candidate-side personal agents
• Cross-organization referral workflows
• A marketplace of specialized recruiting agents

The long-term goal is for PipelineOS to become a shared recruiting workspace where people and multiple specialized agents can collaborate safely, transparently, and with clear human accountability.

Built With

• firebase
• firestore
• node.js
• react
• render
• tailwind
• typescript
• vitest
• webmcp