How we work
Good practice, written down.
Eupraxia means good practice. This page is the short version of ours; the book is the long one.
Six rules we don't bend
- 1
One workflow per Sprint.
Narrow input, narrow output, one user, one measurable improvement. Scope creep erodes margin and quality at the same time, so the Brief names what is out.
- 2
Evals before code.
The output rubric is written on Days 2 and 3, scored 1 to 5 with worked examples at every level, and the prototype is graded against it before anyone calls it done.
- 3
A person stays in the loop.
Every first version drafts, suggests or summarises; a human accepts it. Autonomy is earned later, by your team's decision.
- 4
The model is chosen per workflow.
We are independent of every model vendor. Prompts, model names and settings live in a config file your team owns, so switching models is an edit, not a project.
- 5
Your stack, not ours.
Ten days is too short to introduce infrastructure, so we don't. Your product, your data sources, your AI provider.
- 6
We say no on Day 1 when we should.
If the one-sentence Brief won't fill, or the data isn't ready, the Sprint doesn't start and you keep the scope.
The Day 1 sentence
Under it goes one value line: for an internal workflow, the hours a week the work takes today, times the loaded hourly cost, times 52. For a customer-facing workflow, the deal or retention metric it moves. Both numbers are written down before anything is built.
For a founder, when the month-end close happens, the workflow will pull the metrics and draft the investor update and produce a send-ready draft, so that the update takes 8 minutes instead of 90.
For [user], when [trigger or input] happens, the workflow will [process or action] and produce [output], so that [business value].
The rubric scale
The scale is fixed; the dimensions (accuracy, clarity, tone, completeness, format) change per workflow.
- 1Unusable
- 2Needs a major rewrite
- 3Usable with significant edits
- 4Good with minor edits
- 5Ready to use
Where the method comes from
The three phases, scope, validate and deliver, are the ones the forward deployed teams at OpenAI and Anthropic describe, and the ones Palantir ran for two decades. The book covers each in a chapter, with the templates we use in the appendix. Read about Forward Deployed AI Engineering.
Day 1
Scope
One signed sentence: for whom, on what trigger, producing what output, worth what. If the five brackets won't fill on Day 1, the Sprint isn't ready, and we say so.
Days 2 to 5
Validate
The output rubric is written before the code. A working prototype runs on your real data by Day 5, or you stop and get your money back.
Days 6 to 10
Deliver
Edge cases, error states, prompt tuning against the rubric. Day 10 is a staging deploy or a production-ready pull request, plus the playbook your team runs without us.
Terms we use
- Forward Deployed Engineer
- An engineer who embeds inside a customer's team and ships inside their codebase. Palantir's model, adopted by OpenAI and Anthropic in 2026.
- FDE Sprint
- Eupraxic's fixed-scope engagement: ten business days, one workflow, fixed price.
- Workflow
- A process one user runs with a clear input and output. The unit of work in a Sprint; never a "feature".
- Sprint Brief
- The one-to-two-page document signed on Day 1 that fixes scope, acceptance criteria, the value line and what is out of scope.
Want one useful AI workflow in your product?
Score your workflow in two minutes, then book a 15-minute Scoping Call. If it fits, you leave the call with a Brief draft and a kickoff date.