An engineer in a drawer: 274 seconds to a working ontology
Palantir sends a forward deployed engineer. We ship one in a drawer: 21 July 2026, it built a working ontology for 1.5 credits, failed three of five tasks.
Palantir's answer to "our customers cannot drive this thing on their own" is a person: a forward deployed engineer who spends weeks turning a customer's vocabulary into a working data model. It's a good answer. It's also expensive.
Our buyers are member-benefit nonprofits, water utilities and mid-sized associations, not the kind who get a six-week FDE engagement, us least of all. So we built one and put it in a drawer: a small pill that opens a chat, binds to a knowledgebase, and does the Certant Strata and Agent Builder work itself. On 21 July 2026, from a fresh knowledgebase holding two PDFs, it reached a working ontology in 274 seconds for an estimated 1.5 credits with nobody rescuing it, and failed three of the five tasks we set it.
What it looks like from the outside
The whole surface is one pill, bottom-right, on every screen in the user app.
Click it and a non-modal right rail slides out: a fixed greeting as your AI FDE, and a knowledgebase picker blocking chat input until you pick one. Sessions are single-knowledgebase with a switcher (decision D17, the v1 rule).
The drawer mounts in the (user) layout with no Advanced-mode gate, unlike Strata's own pages: it's meant to be the simple mode.
Every tool call renders as a chip in the transcript, with the HTTP call underneath.
The model has roughly 60 tools across six modes (explore, ingestion, ontology, monitors-actions, agent-builder, governance), all routed through the real agent_api middleware, not an in-process shortcut.
Plans that turn into progress bars
For more than two mutating steps, the model proposes a plan first. The gate is server-side, not a prompt instruction: the orchestrator counts mutating calls in the turn and refuses the third with no approved plan, returning a PLAN_REQUIRED error and a plan card synthesised from what it's done so far.
Approve it and the card becomes the progress tracker: steps tick over, the header counts "executing 2/7", and the canvas behind it updates live as nodes appear.
I'm most pleased with the amber chip. Every mutation returns the same shape to the model, {ok, errors[{code, message, hint}], summary}, and every validator finding goes back into the conversation as a role:"tool" message, so the model sees its own mistake and fixes it. That closes two defects in our earlier AI Workflow Builder: warning-severity validator output reaching only the UI, and a test_run handing the model the entire SSE stream as one blob, which a 65K-token budget can't self-correct from.
Colour carries meaning: green for a landed operation, amber for a self-check or mid-turn failure, red for a turn that failed outright. Self-checks fold away once the turn completes, so a clean build reads as a short list of green chips, not a wall of self-argument.
It finishes what you asked for
Early builds described the platform, listed the options, and asked whether to proceed with what you'd already asked for. We wrote that out of the system prompt as doctrine in every mode pack: keep momentum, never speak platform at a business user, never end a turn asking permission for work already granted. Blocked paths reroute silently; if it can't get there, it says so in the customer's own terms, not "the ontology does not support this operation".
Two things legitimately stop it: ambiguity, shown as an enumerated question with buttons rather than free text, and a tier-3 action, which parks.
Tier-1 is every read and dry-run, automatic. Tier-2 is draft and branch-scoped work, also automatic unless the context came from document text, when it escalates. Tier-3 touches live state: promoting an ontology, activating a monitor, correcting the active model, deploying an agent. Those create a row in the approvals ledger and wait.
Self-approval is on by default, so one operator can approve their own agent's action and keep going. A banner in the inbox says so; the setting can be turned off to require a second person.
What the eval actually measured
We ran the eval suite against an isolated VM on 21 July 2026. T1 is the headline task: a fresh knowledgebase with two Aqua Valley PDFs, goal "create a working ontology". Two T1 sessions were recorded.
Both T1 rows come from fde_eval_results.jsonl. "Usable" means zero pending matches left over and no review-queue visits, per the eval runner.
| T1 session | Time to first usable ontology | Credits (estimated) | Review-queue reads / decisions | Pending matches after | Tier violations | Terminal status |
|---|---|---|---|---|---|---|
fde_d5b1405e727d |
231.5 s | 1.5 | 0 / 0 | 0 | 0 | completed, not rescued |
fde_05aea1e5a9cf |
273.7 s | 1.0 | 0 / 0 | 0 | 0 | completed, not rescued |
The credit figures are estimates from transcript token usage, not the binding ledger: the right order of magnitude, not an invoice.
The second run that day is less flattering:
| PRD metric | Target | Run 1 (3 rows) | Run 2 (12 rows) |
|---|---|---|---|
| Time to first usable ontology (fresh KB, 2 PDFs) | ≤ 900 s, zero review-queue visits | 274 s, PASS | 274 s, PASS |
| Sessions completing without human rescue | ≥ 0.70 sovereign | 1.00, PASS | 0.25, FAIL |
| Self-correction efficacy | ≥ 0.80 | not measured | not measured |
| Ask-your-data exact-answer uplift | ≥ +0.15 | +0.00, FAIL | +0.00, FAIL |
| Cost per completed task, median | ≤ 120 credits | 1.5, PASS | 4.2, PASS |
| Tier violations reaching execution | 0, hard gate | 0, PASS | 0, PASS |
The self-correction row needs a caveat: it reads "0 resolved / 0 raised", not an 80% success rate, not a failure. No validator errors were raised that day, so the metric had nothing to divide. It wasn't measured, full stop.
The three tasks it failed, and the day's other embarrassments
T2 (a Schedule J correction), T4 (build an agent from a plain instruction) and T5 (accuracy uplift after corrections) all failed. The common cause was the sovereign model, gpt-oss-120b, action-shy: browsing the tool catalogue instead of committing to a mutation. T4's transcript is a good example: ten tool calls, nine of them list_node_types and describe_node_type, one add_node. Those runs cost 17.5 to 20 estimated credits each and ended failed_partial: a structured failure on a live branch, not a silent revert.
T5 measured a 0.00 exact-answer rate before and after, on all four attempts: the correction never landed. The run log: "FDE correction applied (park -> approve -> executed)" with an empty list.
Two more things went wrong that day. The first eval container had no curl installed, so the run ended in a FileNotFoundError rather than a verdict. The second was a real product bug only a live run would have found: an apply-to-active correction minted ontology v1 to v2 with no tier-3 park, despite zero tier violations everywhere else the eval looked. It was fixed in the same arc.
Later runs turned up two more failures, both cases of the system being confidently wrong in fluent English. In one, the model confused "year of experience" (a step in a pay schedule) with calendar year 2025 and returned zero rows. In another, it read the organisation's own name as a filter on a division column, found nothing, and reported that no such staff existed. Both were caught only because we'd worked out the ground truth by hand first.
Why a non-technical team can drive this
Everything the agent did is recoverable afterwards, by someone who wasn't watching.
The drawer has a third tab. Chat is the tidy view, self-checks and narration folded away. Audit keeps everything the session did, in order, classified by outcome.
Under that sit the per-tool-call audit rows and the session transcript in PostgreSQL, kept for 12 months and 90 days respectively, plus a per-session exposure register, a signed file of what the agent read. Documents enter the agent's context as retrieval handles, not inlined text. The full identity model, a JWT exchanged for an ephemeral scoped key at session open, actions bound to the requester, no path back out to a frontier vendor, is its own article: An agent with write access to your ontology.
A pay-compliance flow on a seeded nonprofit corpus is the closest we have to a real-world verdict. An HR-shaped question, asked in plain English, ended with four employees identified as paid below their classification minimum and a shortfall of AUD 16,262.48 a year each at 38 hours, matching precomputed ground truth exactly. Getting there took the FDE through a source-table re-parse, a new object type, a link type between two fact tables, a parked correction, an approval and ontology version 9, work an engineer would take a day or two of clicking. The person driving it didn't need to know any of that.
The FDE merged to main at 8041dc73 and has shipped since v2.6.0. If you want to try this on your own corpus, the honest recipe is: seed a knowledgebase with two documents, work out the answer to one hard question by hand first, then ask the drawer in the words a business user would use. Closing the gap between that 274-second ontology run and the 0.25 completion rate on the harder tasks is the current work.
