AI Workers provides the full lifecycle of a synthetic workforce. Administrators define worker identities, each with a display persona, a role, a system prompt that shapes tone and expertise, and generation parameters such as token budget and temperature. Every worker carries a work queue, a durable conversation thread and a set of connected assistants through which it can be reached or through which it reaches out. Workers query live operational data, execute writes and state changes, run scheduled tasks unattended, watch for exceptions, extract structured information from documents, and act as reviewers and approvers within business processes.

Two response paths sit behind every worker and are chosen automatically. When an external assistant is connected and reachable, the platform dispatches the request to it and receives the answer through a signed, authenticated callback. When no external assistant is available, a built-in model runs directly against the same governed tool set, so a worker is never mute and never answers from stale context. Both paths draw on one shared registry of enterprise tools, guaranteeing that a worker behaves identically whether an external assistant or the built-in model is doing the thinking. Conversation, queue management, worker configuration, model provider settings and connected-assistant registration are all managed from a single AI management surface.

At the centre sits the AI Worker: a persistent identity with a name, a role and a memory of everything it has been asked. A worker is defined less by code than by three things that surround it. The first is a role, which carries the worker's permissions and is the sole authority for what it may see and do; a worker can never exceed the boundary its role describes, and changing that role changes the worker's reach immediately. The second is the work queue, an ordered backlog of tasks the worker owns, each with a priority, an optional schedule, a lifecycle from queued through in progress to a settled outcome, and a recorded result. The third is the conversation, an append-only record of user, worker and system turns that gives every exchange continuity and a full audit trail.

Around these sit two supporting concepts. A model provider describes which reasoning engine powers a worker, resolved at the moment of use so an individual worker can override the organisation's default without any change to the worker itself. Connected assistants describe the external tools a worker can be routed to, each with its own endpoint, credentials and health. The relationships are deliberately simple: a role shapes many workers, a worker owns one queue and one conversation and may hold several connected assistants, and a provider may power many workers. Nothing here belongs to a customer or a ledger; this is configuration and persona, held in the platform's core so that identity and permission are governed in one place.

The everyday interaction is conversational. A user opens the worker panel, selects a worker by name and role, and types a request. The message is recorded and acknowledged instantly, then dispatched without blocking the interface. If a connected assistant answers, its reply arrives through the callback and replaces the pending indicator; if none does, the built-in model composes the answer directly, calling whatever governed tools the request requires and returning grounded, data-backed prose. The panel keeps itself current through adaptive polling that quickens during active exchanges and relaxes when the thread is quiet.

The second flow is autonomous. A user schedules work, and the item joins the worker's queue with a priority and, where set, a future run time. The scheduler picks up queued items, runs them through the model against the live tool set with a bounded number of reasoning steps, and records the outcome. A task that completes cleanly is marked as such; one where every action succeeded but some were declined or errored is surfaced honestly as a partial result with a clear notice for human review; one that fails outright is recorded as failed. The third flow is inbound: external assistants connect to the platform's own protocol endpoint and operate the same governed tools under scope enforcement, so a worker's capabilities are available inside the tools people already use elsewhere.

What makes the module trustworthy is that capability and authority are never separated. Permissions are enforced at the moment a tool runs, not merely when a task is queued, so a role change or a worker suspension takes effect on the very next action. Each tool declares a scope, and that scope maps to a concrete permission pair that is checked against the worker's role before the tool does anything; a worker that lacks the right returns a clean permission-denied result rather than acting. If a worker's permissions cannot be loaded for any reason, the system resolves to deny-all, failing safe by construction.

The security posture is layered to match. Interactive access runs under authenticated sessions with capability checks on every route. Outbound dispatch to external assistants is signed with a keyed message authentication code so recipients can verify origin, and each dispatch carries the worker context, a bounded slice of conversation history and a single-use callback address. Inbound callbacks authenticate with a bearer token checked against a stored hash, are rate limited per worker, are size bounded, and are idempotent so a retried delivery never duplicates a reply. Stale exchanges expire on a timer, unreachable assistants are health-monitored and stood down automatically, and every message creation is audit-logged with the acting identity and origin address. The result is autonomy with a paper trail: workers act quickly, but always within a boundary that can be inspected after the fact.

AI Workers is the connective tissue of Nashua 360 rather than an island. Through the shared tool registry a worker reaches directly into Business Relations to read and maintain companies, contacts and locations; into Accounting and Control to interrogate debtor and creditor invoices and the wider financial picture; into Catalog Management to search the layered product and service catalogue; and into Test Management and the core System module for platform metadata and diagnostics. Every one of these reaches is gated by the same role-to-scope mapping, so a worker built for finance sees the ledger but not the catalogue unless its role says otherwise.

Because the module lives in the platform core beside roles and module registration, it inherits the suite's identity and authorisation model wholesale rather than reinventing it. A worker's role is expressed in the same permission grammar as a human user's, which means governance, review and least-privilege design are a single discipline across people and synthetic workers alike. New capability added to any module becomes available to workers the moment its tool is registered, so the conversational and autonomous surface grows in step with the rest of Nashua 360 without bespoke integration work.

Inside the module the workers are the actors, and their range is broad. They answer questions by querying live module data and returning grounded summaries, so a user can ask for an outstanding creditor balance or a customer's recent activity and receive an answer drawn from the current state of the ledger and the relationship records rather than a stored report. They execute actions on request or on schedule, creating and updating records, raising work items and driving multi-step processes through a bounded reasoning loop. They watch for anomalies and exceptions, and when a scheduled task ends with declined or failed actions they raise a warning notification and a clear system message rather than letting a partial result pass silently.

They process documents and unstructured input, extracting structured fields for downstream use, and they support decisions by assembling and explaining the data behind a choice. Crucially, a worker can stand as an approval or review node within a workflow: routed a request under its own permissioned identity, it evaluates the item against its role and instructions, records its determination in the conversation trail and either advances the process or returns it for human attention. Because everything a worker does runs through the same governed tools, the same permission checks and the same audit logging as any other actor in the suite, an AI Worker is a genuine colleague in the process, accountable and bounded, not an opaque automation running to one side of it.