Atlas Field
Dispatch dashboard with an agent that plans, calls tools and waits for a dispatcher's approval.
Atlas Field is a concept for software used by people in vans and on sites, not at desks. The product is genuinely complicated, and most sites in the category respond to that by saying nothing specific at all.
- AI pattern
- Agentic workflow · tool calling
- AI component
- Dispatch triage agent
- Typical timeline
- ~8 weeks
- Maps to
- AI Agent (custom scope)
Atlas Field is a fictional company — this is the build plan we execute for a business like it.
Try it live
Use it, don't just read about it.
An agent reads a job, writes a plan, calls CRM, crew, maps, calendar and SMS tools, then proposes an assignment you approve — with the full trace beside it.
- 01Watch the plan and tool calls stream in
- 02Open any tool call to see its validated result
- 03Approve, edit or reject the proposal
- 04Try the gas-smell job: the agent stops and escalates
Scripted and deterministic so it runs anywhere. In production the same interface runs on live models, your data and your systems.
01The problem
What's really in the way.
Complex B2B products get marketed in abstractions — 'streamline your operations' over a gradient blob — because the specifics are hard to show. The specifics are also the only reason anyone buys.
- 01
Two audiences with opposite needs: an operations lead who wants proof, and a finance approver who wants the shape of the cost.
- 02
The product's value only becomes obvious when you can see the interface doing the work.
- 03
A long, considered buying cycle, so the site has to be useful on the fourth visit as well as the first.
02What we'd build
The scope, plainly.
An operations dashboard for a field-service business, and an agent that reads incoming jobs, checks crew availability and skills, and proposes an assignment that a dispatcher approves with one click.
Dispatch board
Live job list, crew status and a timeline view, built for a dispatcher who lives in it all day.
Triage agent
Classifies urgency, checks skills and travel distance, and drafts an assignment with its reasoning shown.
Human approval
The agent never dispatches on its own. Every proposal is approved, edited or rejected, and that decision is logged.
Typed tool layer
The agent can only call a small set of permissioned, validated tools. Nothing reaches the job system unchecked.
03Architecture
How the pieces fit.
Models are the swappable part. The tools, rules, logging and tests around them are what make a system dependable.
- InputsL1
- Job intake form
- Email-to-job parser
- Existing job system API
- AgentL2
- Classifier + planner
- Typed tools: get_job, crew_availability, propose_assignment
- Schema validation on every call
- PeopleL3
- Approve / edit / reject
- Escalation to a supervisor
- OperationsL4
- Run trace for every decision
- Scenario test suite
- Alerting on failures
- Next.js
- TypeScript
- LangGraph / OpenAI Agents SDK
- OpenAI / Anthropic tool calling
- Zod-validated tools
- Postgres
- Twilio SMS
- OpenTelemetry traces
04Screens
The interface, working.
Captured from the live demo in a headless browser — not mockups.
05Deliverables
What you'd own at the end.
- Dispatch dashboard (web, responsive)
- Triage agent with three to five permissioned tools
- Approval workflow and audit log
- Scenario test suite run before every release
- Integration with one existing job or CRM system
- Runbook and handover
06Typical timeline
Shipped in ~8 weeks.
- Workflow mappingHow jobs arrive, who decides, edge cases
- Dashboard buildBoard, crews, timeline
- Tools & agentTool layer, prompts, validation
- Scenario testingReal past jobs replayed as test cases
- Pilot with dispatchersShadow mode, then approval mode
Schedule fixed in writing at kickoff.
07Approach
Decisions we'd take first.
Strategy
Show the product. Then structure the site so each audience can go as deep as they need without the other one being lost.
- Interface as the heroReal screens, annotated, instead of decorative illustration — the fastest way to make a complex product legible.
- Progressive depthEvery capability has a one-line version, a paragraph version and a full page. The visitor chooses the depth.
- Pricing shape, earlyCost structure is explained before the demo request, because hiding it only filters out serious buyers.
Design
A technical, precise system — tight grids, mono labelling, restrained colour — that borrows credibility from the product rather than from marketing polish.
- Annotated screensA consistent callout treatment turns product screenshots into explanations.
- Mono as signalMonospace reserved for data, labels and indices, giving the page a technical register without decoration.
- Dense, not crowdedInformation density is high by design, controlled with rules and alignment instead of whitespace alone.
Engineering
Server components throughout, with interactivity confined to the small number of places that genuinely need it.
- Islands of interactivityThe feature explorer and the pricing calculator are the only client components on the marketing site.
- Content as dataFeatures, plans and FAQs are typed configuration, so a copy change never touches a component.
- Measured, not assumedInteraction cost profiled on a mid-range Android, which is what the actual audience carries.
08Intent
What it's designed to do.
Success criteria are agreed and measured from launch.
- Take the repetitive first pass off dispatchers while leaving every decision with a person.
- Make each agent decision explainable after the fact.
- Fail safely: when the agent is unsure, it escalates instead of guessing.
- Start in shadow mode so the team can judge it before relying on it.
Your project
Want a plan like this for your business?
Book a 30-minute call. If it's a fit, we'll send a written scope and fixed price, or suggest starting with a $500 pilot.
Or email hello@xaevora.com · reply within one working day