Process Sentinel

• 

  Process Sentinel Architecture

What it does

Process Sentinel is a cognitive/work prosthesis for long-running professional work. It processes work events through a deterministic action boundary and returns one of three outcomes: STAGE, AUTO_CHECKPOINT, or SURFACE_GATE.

Mature work with high loss risk can be preserved without interrupting the user. Low-risk work stays staged. Decisions that change direction or require human authority are surfaced explicitly. The goal is not more AI conversation; it is less interruption with better continuity.

The v0.2.2 prototype adds durable event receipts and replay protection: replaying the same event returns REPLAYED without duplicating process-state rows, while changed content cannot silently reuse an already committed event ID.

Inspiration

Long-running skilled work creates a second job: remembering what is mature, what can wait, what must be preserved before a session disappears, and what truly requires a human decision. That continuity burden consumes the same attention needed for the actual work.

Process Sentinel grew from that real workflow problem. During this hackathon, the AI-assisted process itself became a working example: technical execution could continue while the human retained goal, validation, and authority gates.

How we built it

The prototype uses the Strands Agents SDK with Amazon Bedrock and Amazon Nova 2 Lite (eu.amazon.nova-2-lite-v1:0). Deterministic Python owns classification, persistent state, event fingerprints, replay handling, and human-gate policy. Strands/Nova acts as a constrained orchestration and confirmation layer over the exact registered event rather than reconstructing the event payload.

The three actions are STAGE, AUTO_CHECKPOINT, and SURFACE_GATE. Routine continuity work remains in the background; a gate appears only when human authority or direction is required.

Challenges we ran into

An earlier candidate exposed two important runtime mismatches. Model-shaped optional values could turn null into empty strings and create false event-ID conflicts. A live run also showed that a model could describe a gate without durably committing the state change. We corrected both by canonicalizing optional fields and moving persistent action ownership into the deterministic core.

Accomplishments that we're proud of

The verified v0.2.2 live path produced the expected first-pass outcomes for all three sample events, wrote exactly one checkpoint, one staged record, one human-gate record, and three durable receipts, then returned REPLAYED for all three events on the second pass without adding duplicate state rows.

The project also keeps an explicit boundary between execution autonomy and human authority: the system may protect continuity, but it does not silently change the user's goal.

What we learned

A useful professional agent does not need maximum autonomy. It needs the right autonomy. Durable continuity work can be delegated broadly while human goal-setting, direction changes, and authority remain explicit gates. Reliable agent behavior also depends on making persistent state deterministic instead of asking the model to remember or reconstruct it correctly.

What's next

Turn the current event-driven prototype into a longer-running continuity layer with more input adapters, richer checkpoint destinations, recovery views, and explicit provenance for what was preserved and why. The next step is not to remove the human; it is to reduce needless interruption while keeping the human in control of direction.

Built With

• amazon-bedrock
• amazon-nova-2-lite
• aws-cli
• python
• strands-agents-sdk