Agentic AI · Workforce planning
Talent Estimation Agent
Validate talent requests from a WBS, with numbers you can trace.
- 6specialised agents
- 2independent estimation methods
- 94%test coverage
- 0files or keys stored on the server
Overview
Why it exists, and what it does
The problem
Validating a talent request means reading a WBS, deciding which roles every work package needs, and estimating FTE per role. Done by hand it is slow, and the numbers are hard to trace back to a reason.
The approach
An agentic system reads the WBS and the request document, decides the roles per work package with a written reason, estimates FTE with two independent methods, and reviews its own output before handing a workbook to a person.
Design principleLanguage models judge and explain. Deterministic code calculates.
Every number comes from a tested calculation engine, never from the model. That keeps the results repeatable and lets a reviewer trace each figure back to an input and a reason.
Walkthrough
Don't just read about it. See each screen.
10 real screens from the app. Pick a tab to see what each one is for.
A plain-language start page: a sample result card, the three steps, and a quick checklist for the model, the capability catalog and the WBS file. A demo with fictional data runs without any API key.
Screenshots are from the built-in demo mode, which uses a fictional project.How it works
Three steps for the user, rules you can read
- 1
Upload
A WBS in Excel, plus optional request documents (PDF, Word, text) and meeting notes.
- 2
Agents assess and calculate
Each item is judged per role, then calculated with Use Case Points and bottom-up estimation. Disagreements are re-checked.
- 3
Review and export
Check and correct any flagged rows, approve the result, then download the Excel workbook and a draft reply to the requester.
How the numbers are calculated
Use Case Points (UCP)
- Each WBS item per role is classed Simple (5), Average (10) or Complex (15) from the number of steps involved.
- Roles that only support an item count for part of it (default 25%).
- Actor weights, then technical (TCF) and environmental (EF) factors. Ratings start at 3 and change only with evidence.
- Points are multiplied by hours per point (15 by default), then converted with hours per day, days per month and project length into average FTE.
Based on Karner (1993), Resource estimation for objectory projects.
Bottom-up
- Working days for each item come straight from the WBS schedule.
- The agent proposes a fair FTE allocation for the workload, following allocation guidance rather than copying the requested headcount.
- Person-days = working days × allocation × headcount, summed per role and converted into FTE.
Both methods run separately. When they agree within ±15% the figure is more reliable; when they differ, the Reviewer Agent re-checks the row.
Architecture
Six agents, each with one job
Every language-model step has a rule-based fallback, which also powers the demo mode and the tests.
- Intake
- Estimator
- Reviewer re-judges up to 2×
- Augmentation optional
- Report
- Code
Orchestrator
Controls scope, ordering, retries, review rounds and the run trace.
- Code + LLM
Intake Agent
Reads the WBS in any reasonable layout (leaf work packages only) and the requested FTE per role from the request document.
- LLM + code
Estimator Agent
Decides primary or supporting role, UCP class and FTE allocation per item with a written reason, then calculates both methods.
- Code + LLM
Reviewer Agent
Compares the two methods and sends rows that disagree back for another judgement, up to two rounds. Flags gaps, overlaps and work that appears only in meeting notes.
- LLM + code
Augmentation Agent
Optional. Maps tasks to capabilities and shows an AI-assistance scenario without touching the baseline numbers.
- LLM + code
Report
Drafts the reply message and fills the Excel workbook with live formulas.
Stack
- Agents
- Python 3.12 · LangGraph · LangChain chat models
- Contracts
- Pydantic v2, structured output with schema validation
- API
- FastAPI on Vercel Python Functions (stateless)
- Excel
- openpyxl, formulas recalculated by Excel on open
- UI
- Next.js · React · Tailwind CSS · Recharts (Indonesian interface)
- Evaluation
- Kedro pipeline (offline)
- Tooling
- uv · Ruff · mypy · pytest · pre-commit · GitHub Actions
- Models
- Gemini, Claude, OpenAI, Azure OpenAI or any OpenAI-compatible gateway, with custom headers and token limits
Quality & privacy
Built to be checked, and to forget
Checked on every push
- Ruff lint and format
- mypy type checks
- pytest with 94% coverage
- Excel formulas recalculated in LibreOffice and compared with the engine
- Tests for the model client: endpoints that refuse certain settings, and budget or quota errors that must not be retried
- Kedro evaluation pipeline
- Dependency lock check with uv
- TypeScript checks on the UI
- Next.js production build
Documented along the phases of the Unified Process (planning, analysis, design, implementation), following Dennis, Wixom and Tegarden, Systems Analysis and Design.
Privacy by design
- No database, and the server writes no files. Every request stands alone.
- Uploaded files are parsed in memory; the API key stays in browser memory.
- E-mail addresses, phone numbers and 16-digit ID numbers are masked before text reaches a model.
- Results live in the browser tab and disappear when it closes.
- The repository holds no real project data. The demo project is fictional.
Want to see it run?
The demo works without an API key. It runs the agents on a fictional project in about 15 seconds.
