Multi-Step Agent Workflow Runner with Cost Tracking
A runner that executes multi-step language model workflows as an explicit graph, with retries, per-step cost and latency tracking, and a trace view showing exactly what happened. Builds the observability that most agent frameworks leave out.
Advanced
Needs a team, real planning, and a supervisor who knows the area.1 semester, 2 to 3 students
5 to ship
3 optional extrasSuggested stack
What you should ship
- Workflow definition format describing steps, dependencies and tool calls as a directed graph
- Execution engine with per step retry, timeout and failure handling
- Full trace persistence recording every prompt, response, token count, cost and duration
- Trace viewer showing a run as a timeline with per step cost and the ability to inspect any step
- Two implemented example workflows with a comparison of cost and reliability against a single prompt baseline
If you have time left
- Replay a trace with one step's prompt modified, to test a change against a recorded run
- Caching of deterministic steps across runs
- Parallel execution of independent branches with correct dependency ordering
The problem
Chaining several model calls together is easy to start and very hard to debug. When the final answer is wrong, the question is which of six steps went wrong, and most tooling in this area cannot tell you. Cost is similarly invisible until the bill arrives.
What you build
An execution engine that treats a workflow as an explicit graph rather than a hidden loop, records everything, and presents each run as an inspectable trace with cost attributed per step.
Why explicit beats autonomous here
An agent that decides its own steps is harder to debug, more expensive and less predictable. A defined graph with model calls at the nodes covers the large majority of real use cases and can actually be reasoned about. Making that argument, and demonstrating it with measurements, is a strong contribution.
The comparison that makes the project
Implement the same task twice, once as a single large prompt and once as a decomposed workflow, and measure accuracy, cost and latency for both. A concrete result such as decomposition being more accurate at three times the cost is exactly what this field lacks and what your report should lead with.
The hard part
Trace storage. Prompts and responses are large, runs are frequent, and a naive schema becomes unusable quickly. Design for it early.
Scope warning
Do not write another framework abstraction layer. Execution, tracing and cost accounting is a full semester. Plugins and integrations are not.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.