Concept & Prototype
As part of some business process redesign work, I developed a proposal and prototype for an agentic workflow-management app, built to create and configure itself.
Where it came from
The company I worked with does grants administration (it's a stellar organization doing wonderful work to bring early childhood education centers and housing to families with lower income across the United States). This work is very hard to manage! Contracts and regulations are different for every funder, and often change midstream. They have some software they use to help manage the workflow, but the apps are in silos that they have to pay to integrate, and the workflow never keeps up with the funders' needs. Plus, they have to pay again to build dashboards so they can see how it's working.
Instead of recommending a new software solution or expensive software integration project, I was inspired to use the new generation of AI-workflow tools to develop an alternative approach. This vision starts with ingesting the grant funder contracts and existing grants data and builds the workflow from the source. As each grant application comes in, agents read the submission and push suggested actions to each role in the grant program roles (program officer, finance, CFO,etc.). If the review process is getting stuck or there is a showstopper problem, agents notify the relevant role. When the rules change because of a new contract or amendment, uploading a new document is all it takes to reconfigure the workflow..
The organizations, grants, programs and workflow details in the demo were created entirely for this purpose and do not reflect actual businesses, grants, or programs.
What the demo shows
Roughly six minutes, running on a fictional grants program with twelve awards in flight. It goes like this.
1 · The queue is the product
The home screen opens on 3 overdue, 3 blocked, 2 due soon. The top card reads: Riverbend Housing Collective — $148,000, 10-day disbursement target breached, 9 days over, owned by Finance. Nobody typed that. It is computed from the contract's ten-day clause and the date the tranche was released. It is not a dashboard — it is a list of things to do, and every item names the person who owes the next move.
2 · Why does it think that?
Explain on any card quotes the clause verbatim — “Funds shall be released to the provider within ten (10) days of the tranche being authorised” — names the document it came from, and says what would clear the item. Every rule in the system traces back to a sentence a named person approved on a known date.
3 · Same records, three queues
Switching role changes the list, not the data. Finance drops to five — the clock items only, because Finance cannot action a signature request. The CFO sees two, both signatures. The Program Officer sees all eight, each naming its owner. One engine, one set of records, three different jobs.
4 · A document changes the rules
This is the beat the whole thing is built around. Upload a contract amendment. About twenty seconds of extraction, then a review screen showing what it would do, with old and new side by side:
- Dual signature threshold: $50,000 → $25,000. Two in-flight records would newly require a CFO signature — named, with amounts.
- Disbursement target: 10 days → 7. One record would become overdue immediately.
- Unresolved. Clauses that carry an obligation but no number, recorded rather than guessed at.
Approve, and it becomes v3. Back on the home screen the queue has reshaped itself: one record moved from due-soon to overdue, two moved to blocked. The work changed because a document did.
5 · Records don't move on their own
After approval the program is on v3, but the twelve existing records are still on v2, with a Move all 12 to v3 button waiting. Records stay pinned to the rules that were in force when their work started. Moving them is a decision somebody makes, not a side effect of approving a document.
6 · A second program, with nothing in common
A spreadsheet of awards creates a second program. Its contract then renames it, gives it a five-day payment clock and a completely different lifecycle — a single payment, no milestones. One provider turns out to be drawing from both programs, and appears in both. Two programs with no structural similarity, one queue, one engine.
How it works
The whole demo is one loop. A document goes in, a person approves what it would change, and the queues on everyone's screen reshape themselves. Nothing in the middle is hand-configured.
Input
Contracts and existing data
A grant contract, a contract amendment, or a spreadsheet of awards already in flight. The same door for all three.
Step 1
Extraction
The model reads the document and proposes changes: a payment clock, an approval threshold, a lifecycle stage.
The model can only emit typed operations against a fixed set of element types. No free text reaches the engine — that schema is the containment story for untrusted documents.
Step 2
Review — by a person
Old and new side by side, each quoting its clause, with the blast radius spelled out: $50,000 → $25,000 — 2 in-flight records would newly require a CFO signature. Nothing is applied until someone approves it.
A clause that carries an obligation but no number comes back as unresolved, not as a confident wrong rule.
Step 3
A new version of the spec
v2 becomes v3. Every rule in it carries the sentence that created it, the document it came from, and who approved it when.
Step 4
One fixed engine reads the spec
The engine never changes. It evaluates the current spec against real records and works out what is late, what is blocked, and who owes the next move.
It generates a specification, not code — which is what keeps a sandbox, a build pipeline and database migrations out of the problem.
Program Officer
Sees everything, each item naming its owner
Finance
Clock items only — can't action signatures
CFO
Signatures, and nothing else
When the rules change, hand it the next document and the loop runs again. Records stay pinned to the rules that were in force when their work started — moving them to a new version is a decision somebody makes, not a side effect of approving a document.
The decisions that make it trustworthy
Handing a language model a contract and letting it change how money moves is the obvious objection. Three choices answer it, and they are the substance of the design.
The model can only emit operations against a fixed set of element types. There is no arbitrary-expression form, so there is no path from document text to an evaluator.
A vague clause becomes an unresolved item on the program page — not a confident wrong rule that quietly routes real money to the wrong person.
One fixed engine interprets what the model produces. That removes the sandbox, the build pipeline and the database migrations from the problem entirely.
What it deliberately doesn't do
- It cannot decide whether the work was done. It routes and clocks milestone verification. It cannot judge that construction is finished — a person still does that, and should.
- It does not write code. Code generation would buy flexibility at the cost of everything the fixed engine makes cheap.
- Nothing takes effect without approval. There is no operation that applies itself, including the ones the model is most confident about.
The demo also has honest rough edges: clocks count calendar days even where a contract says business days, and the role switcher is a cookie rather than real auth — the point being that one set of records produces three different queues, which real auth would only make harder to show.
My role
Concept, product design, and build. The process analysis that prompted it, the interaction model, the containment argument above, and the working demo — a Next.js application with a live extraction pipeline behind it.