Case study · AI and agent design
Nobody could answer how a project’s budget compared to what it actually cost, so I designed an assistant that could.
CASim is an internal AI assistant that makes years of inconsistent construction data answerable.
- Role
- Sole designer, researcher, and front-end developer, plus creative lead and architect: MCP server, agents, prompts, and tooling
- Timeline
- 9 months, kickoff to UAT
- Worked with
- Solo on design, research, and front end. Executive team on data defaults, development team on data cleanup after the naming decisions, IT leadership on the access model
- Status
- In UAT and beta testing
- AnswerableBudget against final financials, including work orders, change orders, and supply markup
- Source fixedChose to clean the source data over a permanent terminology file
- UATNow in beta testing, so the adoption story is still being written
Some details are omitted for confidentiality.
Step 1 · Context
One question was close to impossible to answer: how did a project’s budget compare to its final financials?
Every work order, change order, and supply markup existed in our system. Nothing connected them, so answering took manual assembly across screens, and most people didn’t try.
OpportunityHow might anyone get a trustworthy answer about a project’s financials without knowing where the data lives?
What I did alone
I was the only designer, researcher, and front-end developer on CASim, and I also architected the MCP server, agents, prompts, and skills behind it. One person carried the work from the first question to the interface people use every day.
I interviewed stakeholders about the question that was nearly impossible to answer, audited years of data to find where names, dimensions, and identifiers had drifted, and tested tool behavior in MCP Inspector and Claude Desktop before judging how it felt in the interface.
I designed how the assistant reasons about project data and the access model that decides what it can reach.
I built the MCP server and the front end of the custom interface. The development team’s part was updating the source data, after the naming decisions were made.
Step 2 · Research
I assumed the hard part would be the AI. It was the data, drifted over 20+ years.
Names slipped
The same supply appeared under different names.
Dimensions varied
Sizes were written several ways.
No shared identifier
Several identifiers meant one product, with no link.
An assistant on top of inconsistent data inherits every inconsistency, and it answers confidently regardless.
I worked with 6 project managers to learn how they rebuilt financials by hand, and audited years of data to find where names, dimensions, and identifiers had drifted.
Step 3 · Key decisions
I rejected the faster fix, a terminology file, because it would harden the mess into a permanent dependency.
Fix the source, not the symptom
A definitions layer would translate every variant on the fly, but someone owns it forever. Executives set the defaults and developers updated the data instead.
Gate the connectors, not the creativity
A working server let IT leadership see exactly what the assistant could and couldn’t reach.
The cleanup drew fair pushback about what might be lost. Early results answered it. I also backtracked more than once to cover gaps the first architecture missed. The research behind that call was mine, so explaining it and answering for what the cleanup might miss was my job too.
A terminology file mapping every variant to one meaning was the faster, lower-risk path.
Every new variant would need a new mapping, and answers would only be as good as the last update.
Executives set the defaults and developers corrected the data at the source.
Step 4 · Final design
One server, three clients: Claude Desktop for daily use, MCP Inspector for testing, and a custom interface for everyone else.
With design, research, and the front end all in my hands, a bad answer could be traced to the tool, the prompt, or the data without waiting on a handoff.
Step 5 · Impact
The question that was nearly impossible became answerable.
- AnswerableBudget against final financials, including work orders, change orders, and supply markup.
- UATNow in beta testing, so the adoption story is still being written.
Step 6 · What I learned
Research first, expect pushback, and fix the source.
Research before building
Extra time up front would have avoided the backtracking.
Expect the data to push back
In a 20+ year system, drift is certain.
Fix the source, not the symptom
The harder path made the answers trustworthy.
Working alone sharpened the cost
Nobody else was positioned to catch the gaps in my research, so the checks had to live in how I worked. That is why testing each tool in isolation in MCP Inspector mattered so much.
CASim is in UAT and beta testing. I will update this page as adoption results come in.