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 · A simple inbox
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. The summaries are computed very simply from the contract's ten-day clause and the date the tranche was released, no LLM needed, because of the way the contract is decomposed into functional chunks (more on that below).
2 · Why does it think that?
Explain on any card shows the clause from the contract 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 · A contract change rewrites the spec instead of needing code changes
If the funder changes the rules, the user uploads a contract amendment which is parsed and compared to the original contract. 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.
4 · A judgement call to apply new rules
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.
5 · A second program has a different workflow
A spreadsheet of awards creates a second program. Its contrac has 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, without any code changes.
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 potential problem.
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, which a person can review and resolve.
One fixed engine interprets what the model produces, within a simple and fixed schema. No build pipeline is needed here. Of course, that might be different for a real application... but then again it may not, since the functions are simple and the operations they perform are cheap. Here, there are thousands of operations being performed daily on the few thousand records of grants data, and the database operations are still the step that takes the longest.
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.
- It does not write code..
- Nothing takes effect without approval. There is no operation that applies itself.
The demo many rough edges: clocks count calendar days even where a contract says business days, the interaction design is pretty basic, and the role switcher is a cookie rather than real auth.
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.