Checkpoint

We don't build another AI agent. We build the trust layer that lets humans and AI work asynchronously, so agents keep working while humans only step in at checkpoints that actually require them.

Comment

Inspiration

AI agents are getting good enough to complete real work. But there is one thing an agent should never be able to do: vouch for its own output.

As teams delegate more work to AI, producing the work becomes faster and cheaper. The scarce resource starts becoming verified human judgment: knowing that a real person reviewed what an agent produced and accepted responsibility for letting it move forward.

The tools we use to manage work were not designed for that shift. Traditional task boards were built around humans moving cards. When AI agents are added, they are often treated like another API client without a strong distinction between the actor doing the work and the person authorized to approve it.

We wanted to build that distinction into the architecture itself.

Checkpoint is a work management and trust layer where AI agents are first class participants, but deliberately restricted ones. An agent can receive work, claim a task, perform the work, submit its output, escalate risk when necessary, and request review.

It cannot approve itself.

Only a verified human has the authority to close the task.

This allows teams to give AI agents meaningful autonomy without giving those agents unchecked authority over what actually gets shipped.

We don't build another AI agent. We build the trust layer between AI agents and the work they're allowed to ship.

What it does

Checkpoint is an issue board and governance layer built specifically for teams where humans and autonomous AI agents work together.

Every task moves through a controlled state machine:

TODO → IN_PROGRESS → IN_REVIEW → DONE

An AI agent can be assigned a task, claim it, perform the work, attach its results or code changes, and submit the task for review.

But the most important transition is intentionally unavailable to the agent:

The agent cannot move its own work to DONE.

That transition requires human authority.

For protected approvals, Checkpoint uses Persona to verify that a real human is present. Checkpoint then validates that verification server side before allowing the approval to count.

Every approval creates an accountability trail connecting the work, the agent that produced it, the human who approved it, the review round, and the time authorization occurred.

Checkpoint also introduces risk based review:

  • Routine: can be closed by a verified human
  • Elevated: requires stronger oversight, such as the project's designated reviewer
  • Critical: can require approval from two distinct verified humans

One of the most important rules in the system is that an agent may increase a task's risk level, but it can never decrease it.

If an agent discovers that a seemingly routine task affects authentication, payments, production configuration, or another sensitive area, it can escalate the task. It cannot later downgrade the task simply to make approval easier.

Checkpoint also includes agent assignment and workspace automation. Teams can route work to specific agents, while Dev and Sleep modes control automated workflows. This lets agents continue working independently while preserving the point where verified human judgment must take over.

The result is a workflow built around a simple principle:

Autonomy does not have to mean authority.

How we built it

Checkpoint separates the system into two fundamentally different actors: agents that perform work and humans that authorize work.

External AI agents connect to Checkpoint through an MCP server, allowing clients such as Cursor, Claude Code, or Codex to interact with the same governance layer without requiring modifications to the AI client itself.

Through MCP, an agent can work with tasks, submit results, communicate with the system, and request review.

What it cannot do is approve its own work.

That restriction is not enforced only inside MCP.

Permission enforcement lives in the backend API itself.

Every request is evaluated according to the identity and permissions of the actor making it. Approval and completion authority is deliberately unavailable to agents.

That means an agent cannot bypass Checkpoint simply by skipping MCP and calling the underlying API directly.

We use Persona as the verified human boundary. A successful browser callback alone is not treated as proof of authorization. Checkpoint binds verification to the relevant human, task, and review round, then verifies the exact Persona Inquiry server side before recording approval.

This keeps identity verification connected to the specific action being authorized.

Checkpoint also uses optimistic versioning on task mutations. If multiple agents attempt conflicting operations on the same task, stale writes can be rejected instead of silently overwriting newer state.

Our assignment and Dev/Sleep autopilot system controls how automated work is routed to agents. Agents can operate independently on authorized work, but automation still stops at the human review boundary.

Gemini powers Checkpoint's built in AI assistant, allowing users to understand tasks and project state through natural language. Importantly, the assistant remains subject to Checkpoint's permission model and cannot bypass human approval.

Backboard provides persistent team memory so useful context can carry across conversations and workflows.

ElevenLabs adds voice capabilities to the interaction and review experience.

Tiger Data provides Checkpoint's governance telemetry layer. We record events across the task lifecycle, including task creation, agent claims, work submission, risk escalation, rejection, human approval, and completion. This produces a time ordered view of how work moved from autonomous execution to human authorization.

Vultr hosts our shared Checkpoint infrastructure, allowing agents and human reviewers to participate from different machines and locations instead of requiring the entire workflow to run locally.

All of these components operate around the same security boundary:

The systems helping perform the work cannot grant themselves the authority to approve it.

Challenges we ran into

Our biggest challenge was making the human approval gate structural instead of cosmetic.

It is easy to place an Approve button in a dashboard and tell an AI agent not to click it.

That is not a real security boundary.

We had to design the system around a stronger question:

If the agent actively tried to bypass this rule, could it?

That changed several architectural decisions.

Agent restrictions had to live in the backend instead of only in the MCP interface. Task state could not simply be trusted from the client. Agent credentials and human credentials needed different authority. Risk escalation had to be one directional for agents. Human approval had to be represented separately from the work produced by the agent.

One of our hardest integration challenges was making Persona verification part of the authorization model rather than treating verification as a UI event.

We needed to ensure that the inquiry being approved was the same inquiry associated with the correct human, task, and review round. Checkpoint therefore retrieves and verifies the Persona Inquiry server side before allowing the approval to become authoritative.

We also had to think carefully about automation.

Giving an agent the ability to automatically discover and perform work is useful, but that automation becomes dangerous if the same pathway can authorize its own result. We designed Checkpoint so automation can continue through execution and submission while the final approval boundary remains separate.

Another challenge was deciding what not to build.

It would have been easy to turn Checkpoint into another large project management application with administrators, complex role matrices, dozens of settings, and unrelated productivity features.

We kept returning to the same principle:

Authority should scale with consequence, and the actor doing the work should not control its own oversight.

That principle helped us keep Checkpoint focused.

Accomplishments that we're proud of

We are proud that Checkpoint does not try to compete with AI agents by building another one.

Instead, we built infrastructure for a future where many different agents may already be working inside the same organization.

Our biggest accomplishment is creating a meaningful technical separation between doing the work and having the authority to approve the work.

An agent can be productive without receiving every permission.

A human can review the result without needing to continuously supervise how the agent produced it.

And higher consequence tasks can automatically require stronger human oversight.

We are especially proud of the rule that agents can escalate risk but cannot lower it. It gives an agent the ability to recognize that its work is more sensitive than originally expected without allowing that same agent to reduce its own level of oversight.

We also built Checkpoint so agents can be assigned work and operate independently until human judgment is actually necessary. The workflow can progress through assignment, execution, and submission without continuous human supervision, but when the work reaches review, the authority boundary remains intact.

Different interfaces and AI systems can operate against the same underlying governance model. An external agent can interact through MCP, Gemini can help users understand the workspace, and a human reviewer can authorize the final result through the web application.

Our Tiger Data integration gives us a lifecycle record of those actions, while Persona gives us a stronger verified human boundary at approval.

Most importantly, every completed agent task can have something a normal AI conversation does not:

an accountable human attestation attached to the work itself.

What we learned

The biggest thing we learned is that the difficult problem in agent tooling is not always capability.

It is accountability.

AI agents are becoming increasingly capable of writing code, modifying files, using tools, and completing multi step tasks.

But capability does not answer questions such as:

  • Who reviewed this?
  • Was a human actually involved?
  • Which agent produced this output?
  • What level of risk did the task carry?
  • Who had the authority to let it ship?

Thinking about those questions changed how we approached the entire project.

We also learned that human oversight does not have to mean constantly supervising an AI agent.

An agent can operate independently through most of a workflow. Human judgment can remain concentrated at the point where authority actually matters.

We learned that identity and authorization are different problems.

Knowing that someone is logged into an application is not necessarily the same as proving that a real human is present and authorized to approve a consequential action.

We also learned that adding more AI does not automatically solve the governance problem. Even the AI systems powering Checkpoint itself need to operate within the same boundaries as external agents.

Throughout development, we kept evaluating features by asking one question:

If the agent were actively trying to route around this restriction, would the restriction still hold?

That question removed weaker ideas and made the architecture much stronger.

What's next for Checkpoint

We want Checkpoint to become a reusable trust layer that can sit between any AI agent and the consequential work that agent wants to ship.

One next step is signed attestations that can travel alongside a pull request or deployment, allowing proof of human review to follow the artifact instead of remaining only inside Checkpoint.

We also want to introduce policy as code, allowing organizations to define governance rules directly alongside their projects. For example, a repository could specify that changes touching authentication, payment infrastructure, customer data, or production configuration automatically require critical review.

Another direction is branch and worktree binding, connecting a Checkpoint task directly to the exact code artifact produced by the agent responsible for it.

Checkpoint could eventually integrate directly into pull request, CI/CD, deployment, and enterprise approval pipelines so that verified authorization becomes a prerequisite for consequential automated actions.

Beyond software development, the same model could apply anywhere autonomous agents produce work that carries real consequences.

The long term idea is simple:

AI agents should be able to do more work without automatically receiving more authority.

Checkpoint provides the layer in between.

Built With

  • agentic-ai
  • ai-agents
  • audit-trail
  • authorization
  • backboard
  • elevenlabs
  • google-gemini
  • human-in-the-loop
  • identity-verification
  • mcp
  • model-context-protocol
  • node.js
  • persona
  • postgresql
  • productivity
  • react
  • rest-api
  • risk-management
  • server-sent-events
  • task-management
  • tiger-data
  • typescript
  • vultr
  • workflow-automation
Share this project:

Updates

Submission history