Skip to main content
The Get Technician Context tool feeds a dispatch agent a structured, pre-computed snapshot of your technicians — who’s working today, when, how loaded they are, and who has the right expertise — so it can make a good assignment decision quickly without re-deriving any of it from raw PSA endpoints. It works for ticket-triggered runs and for scheduled (ticketless) sweeps; specifying the technician pool via the ticket’s company or board team requires a ticket, while passing an explicit list of technicians works in either mode.
Turn it on in the agent’s toolbox, like any other tool. Give it to the agents that assign tickets; leave it off the ones that do not, and their runs stay smaller and faster. It pairs with the agent’s Dispatch Decision Framework skill, which the agent loads to interpret the context — and it loads it on every run, because the tool asks for it before returning a result.Switching it on also gives the agent Verify Dispatch Decision, which reserves a booked slot against Neo’s other runs and counts every assignment toward a short-term cap per technician. That one needs no setting and costs no credits.

​
What It Does

It returns, per technician:
  • Calendar — weekday working hours (days flagged “Not working” when off), timezone, holidays, today’s existing appointments, and a wrap- and timezone-resolved “on shift / off shift right now” summary so the agent doesn’t have to re-derive overnight-shift or timezone math itself (it still overlays time-off and holidays before deciding)
  • Workload — the open tickets in the workload window you set (the last N days of activity, not the whole backlog): the count and one row per ticket with the fields the agent asks for (the ticket id and status by default; queue, title and priority on request when your instructions read them), plus, when the incoming ticket has a company, the tickets the technician already has for that company. Closed tickets and tickets whose status name contains Complete are not counted
  • Expertise — the technician’s profile plus PSA-configured skills (ConnectWise and Autotask; plus ConnectWise certifications), prior work on similar tickets, the relevant configuration items or technologies
  • Recent Neo assignments — which tickets the agent recently dispatched to each technician, with timestamps, so it can round-robin fairly across the team and avoid handing consecutive tickets to the same person
  • Teams availability (optional) — from your own M365 tenant: each technician’s live presence (Available / Away / Busy / In a call / Offline / out-of-office), so the agent won’t hand work starting now to someone who’s away or on a break; plus their shift rota (upcoming Microsoft Teams Shifts, with each shift’s label — an on-site client name or an absence marker like Annual Leave), so the agent can prefer whoever is actually rostered on — now or for a future slot; plus their Shifts time off, with the reason you gave it — an absence reason (Annual Leave, Sickness Absence, Bank Holiday) is a hard block for work overlapping it, while a reason that just records where someone is working (London Office, Working from Home, On Call) is read as context, not as absence
The agent uses this to choose an assignee (or to decide the ticket should be escalated or left unassigned), then acts via the PSA API — for example setting the ticket’s owner or adding a schedule entry.
Picking the pool from a ticket’s team is PSA-aware, with a graceful fallback. The agent can source candidates from the ticket’s company team or board/queue team, or pass an explicit list. Board/queue teams are a ConnectWise concept; on Halo, Autotask, and ServiceNow — or whenever the ticket has no board/company team, or the team is empty — the tool doesn’t error. It returns the PSA’s active technicians as fallback candidates and flags that it did so, so the agent knows to confirm each candidate’s team/skill/availability suitability rather than treating the list as a curated team match. Any pool taken from a ticket’s team or from that fallback contains only technicians with a ready profile in Neo: a technician without one has no calendar and cannot be scheduled, and the tool tells the agent how many technicians it left out for that reason. If nobody in the pool has a ready profile yet, the tool returns the whole pool and says so, so the run can still tell you what to fix. Under Technicians, add the people who are missing and complete the profiles that are not ready yet.
Teams availability is fetched only when the agent asks for it. Presence is a current-moment signal (who can take this now); shifts are the rota (who is scheduled on, now and for future slots). Both require the Microsoft Teams — Technician Mapping & Availability integration connected and technicians mapped to their Microsoft user; shifts also read the Teams you selected when mapping (your service-desk Teams). When a piece isn’t available, the agent falls back to PSA calendar availability. It’s the same signal as the Dispatch Ticket action’s “Teams availability” setting, surfaced for agentic dispatch.

​
Why It Matters

Each PSA exposes “is this engineer working today” through a different chain of endpoints with non-obvious field names (e.g. ConnectWise’s mondayStartTime / sundayEndTime on schedule/calendars/{id}, Autotask’s InternalLocationWithBusinessHours + per-resource overrides, Halo’s api/Workday). Asking the agent to reconstruct that on the fly is brittle: a misspelled field name or a missing day attribute leads to silent guesses (“probably Mon–Fri 09:00–17:00”) and engineers scheduled outside working hours. Get Technician Context is the canonical answer to working-hours / availability questions. Custom instructions that reference “engineer’s working hours” or “calendar working days” should let the agent reach for this tool, not derive it from primitives.
If a calendar entry sets someone’s shift, say so in custom instructions. The calendar normally starts at the current moment, so a short morning marker — an “Early Shift 07:00 - 08:30” booking that means the day ends at 15:30 — has passed by the afternoon and the agent no longer sees it. Write the rule the way you already read it (“an Early Shift entry means that engineer works 07:00-15:30”) and the agent fetches the earlier part of the day too. Entries that have already finished are marked as such, so they inform the shift without blocking new work.
Set your technicians’ timezones so appointments schedule in local time. Working hours are reported in each technician’s own timezone. On HaloPSA, Neo resolves that timezone in order — the technician’s agent-level Timezone, then their assigned Workday’s timezone, then your tenant’s default timezone. Setting a Timezone on the technician’s agent record (or their Workday) keeps dispatched appointments inside their real working hours; a technician with no timezone anywhere falls back to your tenant default rather than UTC.

​
How to Use

  1. Build a dispatch workflow (or start from a dispatch recipe)
  2. Switch Get Technician Context on in the agent’s toolbox. Verify Dispatch Decision comes with it
  3. In custom instructions, describe your routing rules — preferred boards, escalation thresholds, who handles what. Reference “engineer’s working hours” / “calendar working days” naturally; the agent will fetch them via this tool
  4. Review assignments in Executions before turning off technician approval
The richer your PSA data — skills on technician records, accurate schedules, configuration items on tickets — the better the agent’s dispatch decisions. This tool only surfaces what your PSA (and connected calendars) already know.