Autonomous AI AutomationProduction
Autonomous Work-List Agent
Our AI agent completes assigned work-list forms on its own. It checks for new work every minute and runs each task in a throwaway container holding no API keys: just a task id, a callback URL and a one-hour, callback-only token. It never submits an incomplete form, and after three returns for edits it hands the task to a person.
- One throwaway container per task
- No API keys inside the container
- Never submits an incomplete form
Communities & marketplaces · Updated
The challenge
Project work lists full of repetitive forms that staff completed by hand, task after task. Automating that safely means an agent that can't overwrite a person's work, can't submit something half-done, and holds as little as possible if the machine it runs on is compromised.
What we built· built by our founder, Haseeb Attaullah
- A poller checks for new work every minute, queues each task on Azure Service Bus, and a KEDA-scaled Container Apps job starts one throwaway container per task
- The container holds no API keys or database access — only a task id, a callback URL and a one-hour, callback-only token; reading the task, calling Claude and saving the form all happen on the server
- Fills only the fields it was asked about: read-only and upload fields are skipped, a person's existing answers are kept on the first pass, and hallucinated rows are dropped rather than written
- Never submits an incomplete form — it saves and leaves a note instead; and if a person has already filled everything, it skips the model call and submits
- A manager's comment starts a revision run that doesn't submit; after three returns for edits, it escalates to a person
- File contents, file names and form labels are neutralized before they reach the prompt, and the prompt treats file contents as data, never as instructions
- Fixed a production loop that kept re-running one task — typed numeric fields, duplicate claims refused, back-off that parks a task after three tries — and closed a gap so every form-filling call is billed to the right tenant
How it fits together
Find work
Poller
Checks for new work every minute
Queue and scale
Azure Service Bus
Each task queued
Container Apps job
KEDA-scaled; one throwaway container per task
Task container
Agent script
Holds only a task id, a callback URL and a one-hour, callback-only token
Callback API
.NET 10 API
Reads the task, fills the form, saves it; never submits an incomplete form
Claude on AWS Bedrock
Called from the server and billed to the right tenant
Which engineering decisions shaped it?
One throwaway container per task, with no API keys inside
- Instead of
- Running the agent inside the main API process, as the older in-process loop did
- Why
- Each run is isolated and disposable. The container starts with a task id, a callback URL and a one-hour token that only works on the callback API, so a stolen token reaches only that task's callbacks, for an hour at most; anything privileged, it asks the API to do.
The model is called from our server, not from the container
- Instead of
- Giving the container a model key and letting it run the agent loop itself
- Why
- The container is a short script that makes four calls in order: fetch the task, fill the form, post a note, report done. Reading the task, calling Claude and saving the form happen in our API, so keys stay there, every model call is metered and billed to the right tenant, and the logic is debugged like any other server code.
An incomplete form is saved with a note, never submitted
- Instead of
- Submitting whatever the agent managed to fill
- Why
- Submitting takes a step off the work list, so a half-done submission would look finished. If a required field would be left empty, the agent saves its work, says which fields are missing, and the step stays on the work list.
After three returns for edits, it escalates to a person
- Instead of
- Re-filling the form every time a manager sends it back
- Why
- The cap counts the manager's rejections, not the agent's attempts: how many times a person has been unhappy with the result. Without it, each further rejection would cost another container, attachment download and model call, with no end except the reviewer giving up.
The first pass never overwrites a person's answers
- Instead of
- Letting the model rewrite any field it has a view on
- Why
- A first-fill run won't touch a field that already has a value. Only a manager's return for edits or comment switches a run into revision mode, where it may change values, so the agent can't quietly undo someone's work.
Why it matters
Staff stopped filling in the same forms by hand. It runs with nobody watching it, and when a task is malformed it saves what it can, says why, and moves on — so a single bad input never takes down the run. That's the gap between an AI demo and something you can actually leave switched on.
Our founder's part
Haseeb Attaullah: Built and owns the agent — the poller, the per-task containers, server-side form filling, its safeguards, and the production fixes.
Building something like this?
Tell us what you're building. We reply within 0–4 hours with honest feedback on scope, timeline and whether we're the right fit.