Automatom — BriefRunner

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 Automatom — BriefRunner

Inspiration

Professionals lose hours to repetitive requests that sit between research and a decision: weekly competitor updates, status summaries, and the first draft of a recommendation. A chat response is not enough; the useful work is gathering context, shaping it into something reviewable, and making the next action obvious without taking control away from the person.

What we built

Automatom's BriefRunner is a Professional Agent for that workflow. A user submits a plain-language request such as “prepare my weekly competitor brief.” The agent creates an inspectable background run, gathers bounded context, drafts a concise structured brief, and stops at an explicit human approval boundary. The result tells the user what happened, what is uncertain, and what deserves a decision.

How it works

The FastAPI service starts a background workflow and persists its state in SQLite. The Strands Agents SDK path composes an agent with two deliberately narrow, read-only tools: lookup_demo_context and draft_brief. When AWS credentials and a Bedrock model are configured, the path uses BedrockModel; the default judge-friendly mode is deterministic and offline so the project is reproducible without cloud credentials.

The demo API makes the boundary visible:

• POST /demo-runs starts a BriefRunner request.
• GET /runs/{runUid} exposes queued, running, and done state plus the structured brief.
• The finished result is awaiting_approval with approvalRequired: true, notificationStatus: pending_approval, and sent: false.
• POST /runs/{runUid}/approve records an explicit approval, but still does not send a message automatically.

Safety and scope

BriefRunner has no arbitrary shell tool, no uncontrolled outbound messaging, and no claim of live competitor data in offline mode. The tool surface is bounded, the output is persisted, and notification remains a state transition that a human must review. A production integration would add scoped credentials, sandboxed execution, audit logging, and an authenticated sender after the approval boundary.

What we learned

The most important design choice was making the approval boundary part of the product contract rather than a note in documentation. We also kept an offline fallback so a reviewer can run the core behavior from a clean checkout and compare the same result every time. The hard part was connecting a real agent SDK path to an existing asynchronous workflow without making the demo look more autonomous than it actually is.

Built for Agents for Humans

This project is entered in the Professional Agents track. It demonstrates how an agent can handle repetitive professional work end to end while preserving human judgment at the moment where an external action would matter.

Built With

• amazon-bedrock
• amazon-web-services
• fastapi
• python
• sqlite
• strands-agents-sdk