The collaboration layer your agent stack is missing.

Every stack has a layer for running agents. None has one for working with them. Sentinel is that layer — a board humans and agents share, one inbox for every decision waiting on a person, and durable loops that survive the wait. You get one place to see what's running and to answer what's stuck.

The collaboration layer your agent stack is missing.

Every stack has a layer for running agents. None has one for working with them. Sentinel is that layer — a board humans and agents share, one inbox for every decision waiting on a person, and durable loops that survive the wait. You get one place to see what's running and to answer what's stuck.

1.

What's running

State, step, iteration, and spend for every agent, live.

2.

What's blocked

Every decision waiting on a person, with a name on it.

3.

What was decided

Every intervention kept as a node the next agent reads.

Built with the people who run the work

  • Color portrait of one person

    Maya Patel

    Staff Software Engineer

  • Color portrait of one person

    Jordan Lee

    Platform Engineering Lead

  • Color portrait of one person

    Iman Okafor

    Senior Product Manager

  • Color portrait of one person

    Noah Williams

    Head of Product Design

Color portrait of one person

Maya Patel

Staff Software Engineer

Color portrait of one person

Jordan Lee

Platform Engineering Lead

Color portrait of one person

Iman Okafor

Senior Product Manager

Color portrait of one person

Noah Williams

Head of Product Design

The problem

Every agent framework makes the AI better at the work. None make you better at driving it.

Agent frameworks assume the human steps out. Sentinel assumes they never do. You review outputs, monitor runs, make the calls only you can make, set priorities, and supply the context that lives nowhere but your head. That work is real, and today it has no home — the decision is in a Slack thread, the reasoning is in a meeting transcript nobody reads, the constraint was agreed on a call, the spec is a doc, the state is in GitHub, and the question is buried in your inbox. Six things break, and they break in a predictable order.

01

Nobody knows what the agents are doing

Runs happen inside the harness and write to a log nobody opens. You find out an agent got it wrong from a customer, not from a test.

02

Agents stop without telling anyone

An agent crashes, times out, or loses its machine. Nothing announces it. The ticket still says an agent is working on it, three days later.

03

Questions land in a channel, not on a person

An agent needs a decision only a person can make, so it posts in Slack. Whoever is awake replies. Nobody owns it, nobody logs it, and the next agent never learns what was decided.

04

Agents wait for no reason, and collide anyway

You cap how many run at once, so agents working on unrelated files sit idle. The two that are editing the same file still run straight into each other.

05

Agents start work that isn’t ready

One task has to finish before another can start, but nothing records that. So agents build against a half-finished migration, and someone orders the board by hand every morning.

06

Every agent reads the whole knowledge base

One flat store means each agent loads all of it, every time. It costs more, it gets slower, and the more you add the less the agent finds what matters.

01 / Observability

You can’t oversee what you can’t see.

An agent fleet fails quietly. Nothing throws, nothing pages, and the first signal is a customer. Being accountable for that fleet means seeing three things at once — what each agent is doing, what it’s reasoning from, and what a person already told it.

What it’s doing

The run, while it’s still running

State, current step, iterations against the cap it declared, spend so far. Live, per agent, without opening a terminal.

Assemble · Reason · Act · Observe

Iteration 3 of 8 · $0.41 · 00:11

What it’s drawing on

The context behind the answer

Which knowledge nodes, which files, which earlier decisions went into this iteration. When an agent gets something wrong, this is where you find out why.

6 nodes loaded, not 412

Every source named, per step

Who has touched it

The human half of the run

Every question the agent asked, who answered it, when, and what it did next. The people part of the work is in the record, not in a thread nobody can find.

Asked, answered, resumed — timestamped

Rated 4.6 / 5 by a named person

Eight agents in one view with state, loop step, iteration, spend and eval score.

Quality stops being asserted and starts being measured — and the failure you can’t see stops being the one that costs you.

Eight agents in one view, showing state, current loop step, and runtime.

02 / Durable runs

A run that stops should not start over.

An agent that hits its limit, crashes, or waits too long usually does one thing: it starts again from the beginning. That’s tolerable when the only cost is tokens. It stops being tolerable the moment a person is involved.

Because the run doesn’t just lose its own work. It loses yours. The question you answered an hour ago gets asked again. The constraint you explained gets explained again. The decision you already made is made again, possibly differently. You did the work, and the system threw it away.

That’s how people learn to stop answering. And an agent whose questions go unanswered is an agent that starts guessing.

Sentinel’s loops hold their place. A run that pauses for a person keeps everything it had — its context, its plan, the step it was on — for six minutes or six days. When you reply, it picks up at the next step, not the first one. Nothing you contributed has to be contributed twice.

That’s not a technical nicety. It’s the difference between working with something and restarting a conversation with it every morning.

A pause costs no progress. Six minutes or six days.

Resumes at the step it stopped on, never at step one.

Your answer is kept, and reused by the next agent that needs it.

Every loop declares where it stops, so nothing runs away.

Three durable run endings: finish, ask, or die.
Three durable run endings: finish, ask, or die.

The loop

Durable by construction, and it always knows how to stop.

Every loop has three strict parts: an initialisation that fixes the objective, constraints, and starting variables; an iteration body; and a termination condition that prevents infinite loops and runaway cost.

01

Assemble

Pull the scoped subtree of context this iteration needs, and nothing beyond it.

02

Reason

Decide the next action against the objective and the guardrails it was given.

03

Act

Call a verified connector, or open a human gate and pause durably.

04

Observe

Score the result, write back what was learned, and check the termination condition.

ENFORCED

Iteration cap

Every loop declares one up front. There is no unbounded run.

ENFORCED

Spend ceiling

Counted per run and visible while it’s still counting.

ENFORCED

Human gate

A durable pause. Six minutes or six days, the run survives it.

ENFORCED

Eval gate

Scored against the step’s output, human-ranked, fed back in.

Who it’s for

Agents aren't assistants. They're headcount.

Team Issue

The person accountable when an agent gets it wrong

Eng lead, ops lead, head of automation. When an agent gets it wrong, it lands on them — and they had no way to see it coming.

The bottleneck is not

Model quality

The bottleneck is

Coordination, oversight, and trust

Solution

The sentinel

Reviews, decides, answers, rates. Wants fewer interruptions, not another dashboard.

03 / Decisions

You answer once. The next agent asks again.

An agent hits a fork it can't decide and pings a channel. The question arrives with no context, so answering it takes longer than the decision does. And when you do answer, it goes nowhere — not to the run, not to the knowledge base. The next agent asks the same thing. The board shows every piece of work and who owns it right now. The inbox holds only what's waiting on you, each request carrying what the agent tried, what it read, and what it's about to do. You reply, the run resumes, and your reasoning is written back as a node — so the next agent starts with the answer instead of asking for it.

Board — every piece of work, one owner, human or agent.

Inbox — only what’s blocked on you, with the context attached.

Replying resumes the run. No restart, no re-explaining.

Your answer becomes a node the next agent reads.

Sentinel board and inbox showing human decisions waiting on an agent run.
The ask flow from agent question through a paused run to a human reply and resume.

04 / Fleet

Concurrency managed by what the work touches.

Every agent publishes its plan and what it intends to touch. Two agents heading for the same code area get serialised; six agents on six unrelated repos don’t. A number in a config file can’t tell those apart.

Agents claim what they’re about to touch, before they touch it.

A conflict is caught before the edit, not in the merge.

The second agent waits, then resumes. It isn’t killed.

Humans see the same claims the agents do.

Fleet concurrency showing one agent holding a code area while another waits without being killed.

Connect your stack

Monitoring, code, observability, cloud, CI/CD systems, messaging, and even homegrown tooling.

Connected sources

ThreadBase

42 channels

alerts enabled

Pipecloud

874 accounts

12,400 records

Chatdock

9.841 conversations

204 open

VaultDB

38 schemes

6.4M rows

Stride

$2.4 MMR

1,204 subscriptions

ThreadBase

42 channels

alerts enabled

Pipecloud

874 accounts

12,400 records

Chatdock

9.841 conversations

204 open

VaultDB

38 schemes

6.4M rows

Stride

$2.4 MMR

1,204 subscriptions

41.2M

records indexed

0

errors

Add integration

Connected sources

ThreadBase

42 channels

alerts enabled

Pipecloud

874 accounts

12,400 records

Chatdock

9.841 conversations

204 open

VaultDB

38 schemes

6.4M rows

Stride

$2.4 MMR

1,204 subscriptions

ThreadBase

42 channels

alerts enabled

Pipecloud

874 accounts

12,400 records

Chatdock

9.841 conversations

204 open

VaultDB

38 schemes

6.4M rows

Stride

$2.4 MMR

1,204 subscriptions

41.2M

records indexed

0

errors

05 / Dependencies

Chain the work, and the board sequences itself.

A task that can’t start yet says so, and says what it’s waiting for. When the blocker lands, the next task is claimable in the same second — nobody has to be watching for it.

Dependencies are first-class on the board, not a comment.

Blocked tasks name their blocker, not just their state.

No agent starts work whose ground is still moving.

Independent branches run in parallel by default.

Dependency graph showing claimable and blocked work with the value of sequencing it.

06 / Knowledge

Organized Knowledge

The knowledge base is a mind map of entities and their relationships. Each task maps to the nodes it needs and the super-nodes above them — which makes scope a permission boundary, not just a token saving.

Nodes and super-nodes, connected — not one flat store.

A task loads its subtree. Everything else is never read.

Answers from the inbox are written back as nodes.

Markdown and Mermaid, so context stays compact and diff-able.

Knowledge hierarchy comparing a flat knowledge base with a scoped hierarchy.

Where it sits

The layer above your harness, not another harness.

Sentinel doesn’t write code and doesn’t replace the runtime you already chose. Every harness will ship its own room. None of them will ship a neutral oversight layer above all of them.

Harness

Claude Code

Harness

Codex

Harness

goose

Harness

Your own

Sentinel above the harnesses, systems of record, and verified connectors.

3 Days

longest a dead run went unnoticed, before

"The ticket said an agent was on it. Nothing had been running since Monday morning. Sentinel moved the card inside the hour and told me what the agent's last action was."

Marcus Webb

Director of Data @ Northlane

Monochrome portrait of Marcus Webb

3 Days

longest a dead run went unnoticed, before

"The ticket said an agent was on it. Nothing had been running since Monday morning. Sentinel moved the card inside the hour and told me what the agent's last action was."

Marcus Webb

Director of Data @ Northlane

Monochrome portrait of Marcus Webb

3 Days

longest a dead run went unnoticed, before

"The ticket said an agent was on it. Nothing had been running since Monday morning. Sentinel moved the card inside the hour and told me what the agent's last action was."

Marcus Webb

Director of Data @ Northlane

Questions

The things people ask first.

Is this another agent framework?

No. Sentinel doesn’t write code and doesn’t run your agents — it sits above whatever harness you already chose, and works across several at once. If you swap Claude Code for Codex next quarter, the oversight layer doesn’t change.

Why not just put the agents in Slack?

Chat is linear, ephemeral, and interrupt-driven. A question scrolls past, and ten agents chatting is ten times the noise for every reader. A queue has an owner and a state; a message doesn’t. Sentinel can read from a channel — it just won’t make one the system of record for decisions.

What happens when an agent asks something at 3am?

The run pauses durably and the request lands in the inbox with an owner. It doesn’t fail, it doesn’t guess, and it doesn’t cost you state while it waits. Answer it at 9am and the run resumes from exactly where it stopped.

How do you stop a fleet from stepping on itself?

Agents publish their plan and what they intend to touch, and conflicts are detected on that basis rather than by a fixed parallelism cap. Two agents heading for the same code area get serialised. Everything else runs at full width.

What stops a loop running away?

Every loop declares a termination condition at initialisation — an iteration cap or a success check — plus a spend ceiling counted while the run is still going. A run that reaches either stops and asks rather than continuing.

Do we have to move our knowledge into Sentinel?

Context is captured as connected nodes rather than one flat store, and built incrementally from where your context already lives — repos, meetings, chat, docs. A task pulls the subtree it needs. You don’t need a finished knowledge base before the first agent runs.

Is this another agent framework?

No. Sentinel doesn’t write code and doesn’t run your agents — it sits above whatever harness you already chose, and works across several at once. If you swap Claude Code for Codex next quarter, the oversight layer doesn’t change.

Why not just put the agents in Slack?

Chat is linear, ephemeral, and interrupt-driven. A question scrolls past, and ten agents chatting is ten times the noise for every reader. A queue has an owner and a state; a message doesn’t. Sentinel can read from a channel — it just won’t make one the system of record for decisions.

What happens when an agent asks something at 3am?

The run pauses durably and the request lands in the inbox with an owner. It doesn’t fail, it doesn’t guess, and it doesn’t cost you state while it waits. Answer it at 9am and the run resumes from exactly where it stopped.

How do you stop a fleet from stepping on itself?

Agents publish their plan and what they intend to touch, and conflicts are detected on that basis rather than by a fixed parallelism cap. Two agents heading for the same code area get serialised. Everything else runs at full width.

What stops a loop running away?

Every loop declares a termination condition at initialisation — an iteration cap or a success check — plus a spend ceiling counted while the run is still going. A run that reaches either stops and asks rather than continuing.

Do we have to move our knowledge into Sentinel?

Context is captured as connected nodes rather than one flat store, and built incrementally from where your context already lives — repos, meetings, chat, docs. A task pulls the subtree it needs. You don’t need a finished knowledge base before the first agent runs.

Humans and agents share the work. Sentinel watches over it.

All systems operational

99.98% UPTIME

Updates on new features and releases.

© 2026 Sudo Labs. All rights reserved.