Decision Gate

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Decision Gate

Inspiration

Small service businesses and solo operators lose hours to routine leads, repeated deliveries, pricing questions, and risky requests mixed into one inbox. Most automation either stops at classification or gives the model too much authority. Decision Gate takes a third path: automate the reversible work, remember what has already happened, and create a hard boundary around consequential choices.

What it does

Decision Gate ingests untrusted inbox events through a Strands agent and assigns each one a durable external identity. A deterministic policy classifies the event before an action can occur. Routine leads produce a locally staged acknowledgement. Repeated deliveries are suppressed across fresh processes. Requests involving money, contracts, safety, credentials, deletion, cancellation, or scope changes enter a human decision queue with reasons and evidence.

The current build never sends a message. It also does not expose approval or rejection as an agent tool. A separate human-only CLI owns resolution, requires an audit note, and prevents a second resolution.

How I built it

The Strands Agents SDK provides the model-facing professional operations agent. Its tool surface contains only event ingestion, pending-decision review, and staged outbox review. The Python engine validates inputs and applies deterministic policy outside the model. SQLite persists events, open decisions, outbox entries, and audit history. A unique external ID makes duplicate suppression survive process restarts.

The public repository includes a reproducible offline demo, an MIT license, a human-only resolution CLI, an architecture diagram, eight automated tests, and a GitHub Actions workflow that publishes the demo result as a downloadable artifact. The hosted evidence explorer reads checked-in output from the same engine and clearly labels the data as synthetic.

Challenges I ran into

The hardest design problem was separating useful autonomy from authority. A prompt instruction is not a security boundary. The final design therefore removes the resolution capability from the model-facing tool set entirely. Durable duplicate suppression also had to work after a process restart, not only during one polished demo session.

Accomplishments that I am proud of

• A working Strands agent with a small, inspectable tool surface
• Cross-process duplicate suppression backed by SQLite
• A no-send outbox that keeps the demo reversible
• A separate human-only decision path with required audit notes
• Eight passing tests, formatting and lint checks, and green public CI
• A hosted evidence explorer and a 2 minute 27 second 1080p demo

What I learned

Human-in-the-loop systems become more trustworthy when the boundary is structural. The useful product is not a promise that the model will behave. It is a system in which consequential actions are absent from the model's capabilities, repeated events are remembered, and every state change remains reviewable.

What is next

The next milestone is a read-only inbox connector plus an authenticated reviewer dashboard. A future send connector will remain behind explicit human release and will consume only reviewed outbox entries. AgentCore deployment is also a natural next step for durable production operation.

Built With

• css
• github-actions
• html
• javascript
• pytest
• python
• sqlite
• strands-agents-sdk