Unblock

• 

  Unblock Overview

• 

  Wrong Receipt

• 

  supplier Follow-up

• 

  Sender Check

• 

  Review Trail

Inspiration

A supplier has completed the work, but an invoice can still get stuck because one supporting document is missing or references the wrong order.

That is the problem behind Unblock. I wanted to build something practical for the person who has to check the paperwork, email the supplier, remember what was requested, and check again when the reply arrives.

What it does

Unblock helps operations teams resolve invoice evidence.

The user creates a case with the expected supplier, invoice reference, order reference, amount, and contact. They upload the invoice, purchase order, and signed delivery receipt. The agent checks the documents against the case details.

In the demo, the case expects PO-1042, but the uploaded receipt says PO-9999. Unblock detects the mismatch, sends a correction request through Amazon SES, and waits.

When the supplier replies with the corrected receipt, the reply starts a new review automatically. A message from a different sender is held for review instead of being accepted as evidence.

A human reviews and accepts the final evidence packet. Unblock does not approve or send payments.

How we built it

I used the Strands Agents SDK with Amazon Bedrock to interpret documents and coordinate the review and follow-up workflow.

The model extracts information from each document, while application code performs the exact checks against the case. This keeps the agent useful without allowing a plausible model response to override a document mismatch.

The application is built with Python and FastAPI and runs on AWS Lambda. Private documents are stored in Amazon S3. DynamoDB stores case state and the activity history. Amazon SQS handles background jobs, Cognito handles authentication, and Amazon SES handles outgoing requests and incoming replies.

The workflow state is saved between runs. This means the browser can be closed while Unblock waits for the supplier.

Challenges we ran into

The hardest part was deciding what should count as valid progress.

An uploaded file is not automatically valid evidence. A sent email does not mean the case is resolved. An incoming reply should not be trusted just because it contains an attachment.

Those decisions led to document matching rules, sender and email-authentication checks, retry handling, duplicate-event protection, and a complete activity trail for the reviewer.

Accomplishments that we're proud of

The complete loop works on the deployed AWS application:

• Create an invoice case
• Upload supporting documents
• Detect a mismatch
• Send a supplier correction request
• Hold an unexpected sender for review
• Resume automatically when the real contact replies
• Prepare a packet for human acceptance

The most important part is that the agent does not simply produce an answer and stop. It can wait for an external event and continue the workflow later.

What we learned

We learned that reliable agents need more than a model call. The surrounding system matters just as much: permissions, state management, retries, validation, audit history, and clear human handoff.

We also learned that a narrow workflow is better than a broad promise. By focusing on invoice evidence, we were able to build and test the full path from an incorrect document to a corrected, reviewable packet.

What's next for Unblock

Next, I want to test Unblock with a small operations or finance team and learn how their document workflows differ from this pilot.

Future versions could support partial deliveries, amended purchase orders, more document formats, and larger teams. The goal is to remove repetitive follow-up work while keeping the final decision with a person.

Built With

• amazonbedrock
• fastapi
• lambda
• python
• s3
• sqs
• strandsagentssdk