> For the complete documentation index, see [llms.txt](https://kb.theloops.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.theloops.io/digitalworkers/ifs-loops-digital-workers/digital-worker-guides/job-intake-manager/core-concepts/architecture-and-capabilities.md).

# Architecture & capabilities

## Overview&#x20;

The Job Intake Manager is built on four agentic skills that together carry an inbound job email from arrival to a created and released service request. It operates autonomously with an exception queue rather than a per-email approval step, running the same Parse, Resolve, Create, Attach workflow for every supported email pattern. This article covers the core skills, the full intake workflow, integration points, and how the system determines when to act autonomously versus when to escalate to a coordinator.&#x20;

## Agentic Skills&#x20;

#### Email & Attachment Parsing&#x20;

Parses the headers, plain-text body, RTF body and the text of every attachment on an inbound email, walking quoted headers where needed to identify the originating platform and the end client. This skill handles attachment variation directly, including PDFs with an empty message body, attachments declaring an incorrect or generic MIME type, and orders split across the body and multiple attachment types. It also performs the first deduplication pass, matching the email against a composite fingerprint of client reference, site and asset before parsing continues.&#x20;

#### Customer, Asset & Service Resolution&#x20;

Resolves the customer from the end client named inside the forwarded mail, the asset from the client-reference cross-reference narrowed by location and model, the location and address by deriving them from the resolved asset rather than string-matching free text, and the service from the asset-scoped catalog. This skill also resolves the service organization and delivery unit from the applicable selection rule, falling back to the client’s default organization when no rule matches. A no-match on customer or service blocks request creation. A no-match on asset downgrades and flags the request rather than blocking it.&#x20;

#### SLA Extraction & Precedence&#x20;

Extracts SLA commitments across the six encodings that appear in client email: absolute datetime, hours duration, a “before” deadline, a priority code with the duration embedded in the label, a defect code decoded in a secondary attachment, and cases where no SLA information is present at all. This skill applies a per-client mapping from priority and defect codes to duration and fulfilment event, parses each encoding form, and applies an explicit, configurable precedence rule when the email body and an attachment disagree. Extracted datetimes are converted into the operating time zone of the resolved service organization, after the resolution chain rather than at extraction, since organization is not yet known when the email is first parsed.&#x20;

#### Request Creation & Exception Handling&#x20;

Builds and posts the service request, setting automatic release only when every mandatory value has resolved deterministically and nothing has been flagged. It stores the returned request identifier, attaches the source email and every file, and adds a further scope for every additional asset the email named, reusing the first scope’s service after revalidating it against the new asset. This skill also owns idempotency: a repeated request carrying an external identifier already in use is rejected by IFS Cloud, and the worker reads that rejection as confirmation the request already exists rather than as a failure to retry.&#x20;

## Intake Workflow&#x20;

The following table outlines the full intake process from email arrival through to request creation.&#x20;

| Stage            | What the System Does                                                                           | Action / Output                                                                      | Channel           |
| ---------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ----------------- |
| Deduplication    | Matches the email against a composite fingerprint of client reference, site and asset          | Skips processing if unchanged, or proceeds if new                                    | Email             |
| Parsing          | Reads headers, body and every attachment, identifies originating platform and end client       | Candidate values extracted for customer, asset, service, SLA and reference           | Email             |
| Resolution       | Resolves customer, asset, location, service and service organization from the extracted values | Confirmed or flagged matches, with candidate sets and scores recorded                | IFS Cloud         |
| SLA Extraction   | Parses the SLA encoding present, applies precedence rule if body and attachment disagree       | Duration or absolute deadline resolved and converted to the organization’s time zone | IFS Cloud         |
| Confidence Gate  | Evaluates whether every mandatory value resolved deterministically with nothing flagged        | Sets automatic release true or false                                                 | IFS Cloud         |
| Request Creation | Posts the request, attaches source materials, adds a scope for each further asset named        | Request created, released or held, notification sent                                 | IFS Cloud / Teams |

Exception paths: When no customer match, no service match, or a credit block is found, the worker holds and escalates without creating a request, since creating a request on the wrong customer costs more than not creating one. When multiple asset or location candidates exist, the worker takes the highest-scoring candidate, creates the request, and flags it for override. When a request-creation call fails, it queues for a bounded retry and then escalates, with every retry carrying the same external identifier so a retry cannot produce a duplicate.&#x20;

## Integration Points&#x20;

**IFS Cloud:** The primary integration. Read-mostly, writing in three places only: request creation, the chosen attachment route, and the add-scope sequence for a second or later asset. Adding a scope is the only case in which the worker touches a request that already exists, and it only ever adds: it never edits or removes an existing scope. No identifier is ever composed by the worker, every identifier it sends came from a prior API response.&#x20;

**Microsoft Teams:** Exception alerts and the review digest. A blocking exception raises an alert to the intake coordinator with the email, what failed, and the candidates considered. Non-blocking flags and overrides ride a batched digest on a configurable cadence, grouped by client.&#x20;

**Loops data store**: System of record for messages, attachments, extractions, candidate sets, decisions, payloads, results and the full audit trail.&#x20;

## Human-in-the-Loop Design&#x20;

The Job Intake Manager is designed so that clean, confidently-resolved jobs create and release automatically, and coordinator judgment is reserved for genuine exceptions.&#x20;

The system creates and releases automatically when:&#x20;

* Every mandatory value, customer, asset, location, service and SLA, resolved deterministically&#x20;
* No candidate ambiguity was flagged during resolution&#x20;
* The SLA extraction succeeded without a body-versus-attachment conflict, or the conflict was resolved by the configured precedence rule without triggering the confidence gate&#x20;

Coordinator review is required when:&#x20;

* No customer match, no service match, or a credit block is found, blocking creation entirely&#x20;
* Multiple asset or location candidates exist, or the address cannot be derived from the asset&#x20;
* Body and attachment disagree on the SLA in a way that fails the confidence gate&#x20;
* The email is portal-gated, with the job detail behind an authenticated link rather than in the message&#x20;

When escalating, the system surfaces the reason, the candidates considered, the scores, and the extracted values, so an override is a single decision rather than a re-read of the original email.&#x20;

## Feedback and Continuous Improvement&#x20;

Coordinators correct the customer, site, asset or service on an exception. That correction is applied to the request and offered as a new entry in the client’s alias or cross-reference table, so the same email pattern resolves itself automatically the next time it arrives.&#x20;

No-match and false-match rates are tracked per client and per field to calibrate matching thresholds. A high override rate on a single client points at that client’s mapping tables rather than at the underlying model. Every exception, recommendation, decision and outcome is logged with full traceability, providing the evidence base for ongoing accuracy review and threshold tuning.&#x20;