Meet ITECS RELAY: AI Support Built Around Clients and Technicians

A browser setting changes. Text becomes difficult to read. Work slows down, and someone emails IT for help. It is a small problem, but it still deserves a clear response—and a straightforward way to reach a technician if the first suggestion does not work.

That is the kind of support experience ITECS RELAY is built to improve. RELAY is ITECS’s automated support assistant, integrated into the service-desk workflow to offer help with clearly understood, simple requests. It asks before starting, stays within standard-user permissions, and leaves unclear or complex initial issues with normal technician handling.

ITECS deployed general intake on September 13, 2026. The rollout applies to new tickets created from the 11:04 UTC activation cutoff onward; RELAY does not pick up the older backlog. This is a real internal deployment, not a demonstration disconnected from the support operation.

A small request, handled with permission

Consider a browser-zoom request. The following examples are illustrative—not actual client tickets, transcripts, or measured results.

An employee emails support because a web page suddenly looks too small. If RELAY clearly understands the issue and knows a short, appropriate approach, it introduces itself as ITECS’s automated assistant. It explains that the ticket is already logged and a technician remains available, then asks whether the employee would like help.

The distinction matters: receiving an automated offer is not the same as agreeing to automated troubleshooting. RELAY waits for acceptance before proceeding.

After the employee accepts, a relevant question might establish whether the problem affects one browser tab or the whole display. A suitable next step could be a simple browser-zoom adjustment. RELAY must not invent details about the employee’s device or the company’s configuration to make its answer sound more certain.

The intended path is easy to understand:

1. Recognize a clearly understood, simple request and offer help.
2. Wait for the client’s acceptance.
3. Ask relevant questions and guide an appropriate standard-user step.
4. Continue when there is a suitable option, or hand off to a technician.
5. Close only after fresh human confirmation that the current issue is fixed.

If the employee confirms that the page now displays correctly and the original problem is fixed, RELAY can acknowledge the resolution and close that issue. The client’s confirmation—not merely the delivery of instructions—completes the conversation.

The handoff is part of the service

Now change the example: the zoom adjustment does not help.

RELAY does not treat one failed step as proof that the client needs the same instruction again. An accepted conversation can continue with relevant questions and another suitable simple step. Whether it continues depends on progress and appropriate options, not a fixed message limit.

If the issue becomes unclear, more complex, or requires privileges the employee does not have, the technician is the next step. RELAY assumes the person contacting support is a standard user. It does not infer permission to change company networks, security settings, policies, or shared systems.

An administrator prompt is a handoff point—not an invitation to coach someone around a restriction. Once a technician takes over, RELAY’s participation ends.

For clients, the intended benefit is less friction on straightforward requests. For technicians, it is a better-informed handoff: a conversation in which the issue, relevant questions, and attempted steps have context. Neither benefit should depend on an employee becoming an IT administrator.

A closed ticket should mean the problem is fixed

Support automation can look productive if it closes tickets quickly. That is not a useful definition of success when the employee is still having trouble.

RELAY requires fresh human confirmation that the current issue is fixed. “Thanks,” agreement to try instructions, partial improvement, and silence do not qualify. A clear fix confirmation followed by a harmless thank-you still counts; later renewed symptoms invalidate the earlier confirmation.

There is a separate boundary for a separate problem. In another illustrative exchange, the client says the browser issue is fixed but mentions a different printer problem. RELAY acknowledges and closes the confirmed original issue, then directs the client to submit a new ticket. It neither troubleshoots the second issue in the original conversation nor creates that ticket for the client.

Automatic messages do not count as acceptance or confirmation, and they do not trigger reply loops. These rules keep the meaning of consent, progress, and resolution tied to a person’s actual response.

Built into the support workflow

The engineering behind RELAY goes beyond connecting a language model to an inbox. ITECS extended its existing HaloPSA connector and marketplace plugin to deploy a resident Linux support agent using Codex reasoning, durable conversation state, and the ATLAS documentation library.

Durable state gives the workflow continuity across exchanges and interruptions. ATLAS gives it a source of documented procedures. Document access is scoped to the verified client’s material and the Global KB; another client’s documentation is not an interchangeable source of context.

ATLAS procedures are preferred, but the absence of an article does not prevent well-understood, simple guidance. The boundary remains the same: general technical knowledge cannot establish facts about a client’s configuration.

The communication layer matters too. RELAY uses its own Halo email template for short, branded messages, preserving other technicians’ signatures. Delivery operations retain receipts across interruptions and reconcile uncertain writes instead of blindly resending them. Independent health monitoring sends incident and recovery alerts while suppressing repeated alerts for an unchanged incident.

These are practical agentic AI engineering decisions: define what the assistant may do, preserve the context needed to do it, verify consequential actions, and return control to a person when appropriate. The achievement is the working integration and its operating boundaries—not a claim that AI can handle every support problem.

Complimentary help without billing guesswork

Quick automated troubleshooting through RELAY is complimentary for managed/unlimited, retainer, and hourly clients.

That statement applies to the automated assistance. RELAY does not decide charges, deduct retainer hours, create billable time, or promise that technician work will be free. A handoff does not give the assistant authority to reinterpret a client’s agreement.

Businesses evaluating ITECS managed IT support should continue to distinguish the support experience from the agreed scope and commercial terms.

What the rollout has proved—and what it has not

ITECS’s September 13 rollout validation recorded:

• 58 Python tests passing locally, with the same 58 passing against the installed Linux runtime and connector.
• 40 scoped Astra policy scenarios and six focused native Linux scenarios passing.
• Passing connector, package, and skill checks.
• Verified operational alert delivery and recovery.

The publicly merged ITECS marketplace update provides a public record of the connector and RELAY support workflow. The team also received a four-page guide with a workflow diagram, 12 fictional scenarios, and operating rules, alongside canonical operations documentation.

These are engineering validation results. They are not customer resolution-rate statistics, time-saving measurements, ROI evidence, a compliance certification, or a guarantee that every interaction will work perfectly. No measured business outcome has been established for this rollout.

The intended direction is clear: make straightforward requests easier to work through and give technicians better context when human help is needed. Those benefits should be evaluated through real operating evidence rather than inferred from a test count.

A practical next step for AI-enabled support

For a business owner, the useful question is not simply whether a provider uses AI. It is whether that provider can connect AI to real work while making permission, accountability, and human handoff clear.

RELAY demonstrates how ITECS is approaching that challenge inside its own support operation: a bounded role, explicit client choice, documented operating rules, and a technician path that remains available.

If you are considering managed support or exploring where thoughtfully integrated AI could help your organization, talk with ITECS. We can start with the workflow, the people it serves, and the decisions that must remain in human hands.

Editorial note: This article describes the September 13, 2026 rollout using ITECS’s approved first-party achievement brief and the linked public marketplace update. Examples are illustrative. Prepared with AI assistance; no client identities or ticket contents are used.