Project profitability as a prompt

Every services-firm operator knows the question, and most can’t answer it on demand.

Which of our active projects are losing money right now, and why?

It’s the right question. It’s not a hard question. But answering it usually means opening the BI tool nobody uses, exporting time data from one system and revenue from another, building a pivot, deciding which costs to allocate where, and — if you have one — finding a moment of an analyst’s calendar. By the time the answer arrives, the quarter is over and the decisions you would have made differently are already made.

This post is what asking the question now looks like, when the agent has direct access to the finance surface.

The prompt

Here’s the actual prompt:

Which of our active projects are unprofitable right now, and why?

Give me a table broken down by container (project), with revenue, cost, gross margin %, and billable-hour utilisation. For any project under 20% gross margin, dig into why — is it an estimate overrun, a staffing-mix issue, or scope creep? Date range: Q1 2026 (Jan 1 – Mar 31).

That’s it. No SQL, no spreadsheet, no dashboard click-path. A founder writes that in a chat window and the agent does the rest.

What the agent does

Behind the scenes, the agent runs a small workflow against the finance MCP tool. Roughly:

1. Calls get_job_role_list, get_cost_center_list, and get_sku_list to learn the install’s vocabulary — what job roles exist, what cost centres roll up where, what SKUs the firm sells.
2. Calls get_profitability with filterBy: container and the Q1 date range. One call, one row per project.
3. For each project under the 20% margin threshold, calls get_item_billable_summary and get_work_estimate_logged — the per-item margin breakdown and the budget-blower flag.
4. Composes the table, narrates the diagnosis, returns the answer.

The agent didn’t write a single piece of data anywhere. The whole finance surface is read-only by design — the books-of-record stay in the books-of-record systems. The agent is strictly the question-answering layer.

The output

A representative result for a forty-person services firm running this against Q1:

Project	Revenue	Cost	Margin %	Billable %
Healthcare SaaS rebuild	$312k	$198k	36%	78%
EU bank Postgres migration	$445k	$389k	13%	71%
Mid-market retainer (eng support)	$180k	$156k	13%	64%
Fixed-price MVP build	$95k	$87k	8%	81%
Internal R&D	$0	$42k	—	—

And the narrative the agent attaches:

Healthcare SaaS rebuild is the healthiest engagement — 36% gross margin, 78% billable utilisation. Mostly mid-level engineers, on-scope. Nothing to action.

EU bank Postgres migration is at 13% margin. Two project items have exceeded their original estimates by ≥40% — the dimensional-model refactor (218h estimated, 312h logged) and the cutover dry-run (80h estimated, 144h logged). This is a scope question rather than a staffing one. Worth a conversation with the client about a SOW amendment before the next phase begins.

Mid-market retainer is at 13% margin too, but the cause is different. Billable utilisation is only 64%, and the time that is billable is staffed disproportionately by senior engineers ($210/h average cost vs. the $145/h blended rate the contract was priced at). Pulling one senior off and rotating in two mid-levels would bring this back to target.

Fixed-price MVP build is overrun. Hard to recover — accept it as a customer-acquisition cost or renegotiate before the next milestone.

Internal R&D is by-design pure cost. Confirm the spend against the Q1 R&D budget.

That’s the bit no spreadsheet does on its own. The numbers are necessary but not sufficient — the diagnosis of why each at-risk engagement is at risk is the part a human operator wants. The agent has the numbers, the per-item context, and enough domain language to articulate the cause in business terms.

A founder reading this on a Monday morning has, in two minutes, the rough shape of a week’s worth of decisions: a client conversation to schedule, a staffing rotation to plan, a fixed-price loss to swallow, an R&D burn to validate. The decisions are still theirs. The clarity of where to spend the decision-making energy is the part that used to take a quarter to get.

What changes when this is a prompt

The first time a founder runs this, the response is usually “huh”. The second time, it’s “let’s do this every Monday”. And the third time, it stops being an exercise and starts being a habit.

What that habit costs has collapsed.

The previous version of this question — for the firms diligent enough to ask it weekly — was a Tuesday-morning ritual where someone exported timesheet data, joined it against invoiced revenue, joined that against the project ledger, ran a margin calc, and emailed a PDF nobody read past the first chart. Cost: maybe four hours of a senior person’s week. Latency: a week behind the data. Friction: high enough that most firms gave up after the second quarter and ran on gut feel.

The prompt version costs two minutes of a founder’s morning. The latency is the latency of whatever syncs into the install — for most teams running headless ops, a few hours at most. The friction is low enough that you can ask weekly. Or on a hunch. Or when an engagement starts feeling off and you can’t articulate why.

That’s the change. Not the calculation — that’s been doable for years. The change is the cost of asking, which is now low enough that the question becomes a habit instead of a project.

Why most ops tools can’t ship this post

Most ops platforms can’t write this walk-through, because most ops platforms don’t ship finance. Linear doesn’t. Neither does Jira, Asana, ClickUp, Notion, Monday, or any of the other names a services firm typically holds together with Zapier and hope. They were built around the work-tracking primitive, and finance was always supposed to live in a different tool.

That’s defensible for an eng-team-only context — if all you do is build software for an internal customer, you don’t need profitability per item. It stops being defensible the moment your firm needs to know — every week, with the same casual reach as “what’s the engineering team’s velocity this sprint?” — whether you’re actually making money on the work.

Which is to say: the post you’re reading is one of the few things only an MCP-native ops platform with a finance primitive can ship. The infrastructure underneath it is twelve read-only calls, walked through here. The surface on top is a single sentence in a chat window.

Both ends matter. The first is what makes the second possible.

---

The finance MCP surface is documented at ekso.dev/mcp-tools/finance. Background on why Ekso is headless-first in the first place: Operations is going AI-native. Most tools aren’t..