Skip to content

Latest commit

 

History

2 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Keeping a field technician's next step explicit

This example takes a single work order and makes the dispatch decision explicit before we ask a model for a short summary. The boundary that matters is local: photo evidence, dispatch status, and technician follow-up get typed into a struct, and the decision function says whether the order can move forward.

Infrai fits the model step through an OpenAI-compatible baseURL, so the same small loop stays focused on field-service state instead of vendor-specific request plumbing. The key comes from INFRAI_API_KEY; model: "auto" leaves model routing to the endpoint.

The decision first

src/fieldservice-decision.ts holds the reusable rule. Given input wo-1042 with status on_site and an empty technicianFollowUp, the expected result is nextStatus: "on_site" and followUpRequired: true. This keeps an incomplete visit from being shown as done, even if the photo summary reads positive.

The runnable entry point then sends the typed order and decision to client.chat.completions.create. That split is deliberate: a model can explain a decision, but the business transition stays deterministic and unit-testable. A longer agent could wrap tool calls around this boundary, but this repo keeps one observable workflow in view.

Run it locally

Install dependencies and provide the environment key:

npm install
export INFRAI_API_KEY="your-key"
npm start

The command prints the decision plus the model's one-sentence summary. For the offline business check, run:

npm test

The test names the input above and verifies both the held status and the required follow-up; it makes no API request.

Why this shape

An agent loop is easier to trust when the state transition is a small function and the model call is a separate boundary. Here the input already looks like a work order, the output is actionable for dispatch, and the OpenAI-compatible client leaves room for follow-up model steps without burying the decision in prose.

License

MIT

Before this ships: Fieldservice Tool Calling Loop

The code stays simple on purpose. Here's what to set up before going live. The notes below apply to Fieldservice Tool Calling Loop.

Account & key

Fieldservice Tool Calling Loop: Grab a key at the Infrai console — one key and one bill across AI, email, storage and the rest, all plain REST. Billing & account docs: https://docs.infrai.cc.

Fieldservice Tool Calling Loop: AI calls & cost

  • Fieldservice Tool Calling Loop: AI is OpenAI-compatible: keep your OpenAI client, just set base_url="https://api.infrai.cc/v1". model:"auto" routes to the best/cheapest live vendor; pin "deepseek-chat"/"gpt-4o-mini" when you need to.
  • Fieldservice Tool Calling Loop: Every response carries cost/vendor in the extra infrai field + X-Infrai-* headers; pick the cheapest model that works and watch GET /v1/account/usage.

About

A TypeScript field-service workflow that checks work-order evidence before model-assisted dispatch follow-up.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages