Give an agent access to traditional tools — MCP servers, databases, a bash terminal. Then extend it one step further: let it reach out to real people, gather context from them directly, and complete the task entirely on its own. That's ARIA.

▶ Watch on YouTube

Every capable agent today gets access to the same two things: tools (MCP servers, databases, APIs, a bash terminal) and skills (code execution, file generation, search). These let an agent act on structured, accessible data.

ARIA extends this with a third layer: people.

When the agent hits the boundary of what any tool or system can provide — because the context doesn't exist in any database, because the knowledge lives in someone's head — it reaches out directly. It emails, calls, or messages the right human, waits for a response, integrates what it learns, and continues. No human has to interact with any UI. No system has to be updated. The agent adapts to how people already communicate.

The result is an agent that can complete long-running, real-world tasks entirely on its own — not because it has access to better data, but because it knows how to go get context that was never in any system.

In oil & gas, manufacturing, retail, construction, and most traditional industries, decades of operational knowledge lives entirely in people's heads. The experienced engineer who knows why that pump failed in 2019. The shift supervisor who noticed an unusual vibration last week. The maintenance technician who modified a valve and never updated the CMMS.

You can't reach that knowledge with an MCP server. You can't RAG your way to it. You have to ask — and then wait.

Current AI agent architectures assume data is already in a system. ARIA assumes the opposite: the most important context is human, distributed, and asynchronous. The agent's job is to identify what it doesn't know, reach out to the right people, wait however long it takes, and synthesize their responses into a structured analysis.

Anthropic's managed agents maintain persistent session state across days or weeks. When ARIA sends an email and goes idle, the session doesn't terminate — it pauses. When a stakeholder replies, the backend webhook routes the email back to the exact session, resuming the agent with full context intact.

This is architecturally impossible with stateless API calls. Long-running human workflows require long-running agent sessions.

A single managed agent session can receive context from any communication channel:

Every inbound message — regardless of channel — routes to the correct live session via webhook. The agent wakes up, reads the new human-provided context, and continues exactly where it left off.

ARIA's first instantiation targets failure mode analysis at industrial facilities. A reliability team uploads equipment sensor logs and maintenance records. ARIA:

1. Fans out 3 parallel FMEA sub-agents simultaneously — one each for rotating equipment, static equipment, and instrumentation
2. Identifies missing context — emails the analyst pool with batched questions
3. Goes idle — waiting hours or days for responses
4. Resumes on each reply — integrating new data, deciding whether to compile or wait for more
5. Escalates up the hierarchy — from analysts (L1) to team leads (L2) to managers (L3) if needed
6. Phone call fallback — if a stakeholder doesn't reply by deadline
7. Generates a 4-sheet regulatory-grade Excel report: FMEA findings, RCM work orders, mitigations, references
8. Routes for approval — draft to team lead, final to full hierarchy

Safety-critical findings (H2S, overpressure, fire/explosion, TBO overruns) always surface first, regardless of RPN score.

A process that takes a team of 4 engineers 3 weeks now runs overnight.

The same architecture applies to any industry where institutional knowledge is not in systems:

The agent selects the right channel per contact from a central contacts registry. Every inbound response — regardless of channel — routes back to the same live session via webhook.

The agent queries a contacts table to determine how to reach someone:

• type: email, phone, sms, slack, whatsapp
• value: the actual address or number
• contact_info (JSONB): full profile — all channels, role, organisation, preferences

One person can be reachable on multiple channels. The agent picks the most appropriate one for context and urgency.

The agent can schedule its own follow-ups without operator intervention:

1. Sends outreach, logs a deadline to scheduled_followups
2. A cron worker fires the follow-up if no reply arrives in time
3. The follow-up is injected back into the session as a user.message — agent stays aware
4. After N attempts, agent escalates to the next person in the hierarchy

ARIA can receive P&ID drawings as file attachments and extract equipment, instrument, and line data directly from the diagram image. The underlying detection model is a YOLOv11m trained on a publicly available P&ID dataset.

Training instructions, dataset setup, and inference examples are in pid-training/README.md.

• Agent: Anthropic Claude Opus 4.7 (managed agent)
• Sub-agents: 3 parallel specialist FMEA agents (rotating, static, instrumentation)
• Compute: Modal agent for heavy compute offload
• Backend: FastAPI (Python)
• Email: Resend (reports@email.areebpasha.com)
• Phone: Retell AI
• Database: Neon Postgres
• Frontend: Next.js
• MCP servers: Exa (research), Context7 (documentation)
• Skills: Anthropic xlsx (Excel generation)

Every outbound email includes [Report #<id>] in the subject. When a stakeholder replies, the backend routes it back to the correct session via two strategies:

1. Subject tag — parse [Report #42] from the reply subject
2. In-Reply-To header — match Resend's email ID against stored outbound threads

The session status filter is always NOT IN ('complete', 'archived') — never = 'pending' — because the agent advances the report through multiple stages as the workflow progresses.

The current implementation is a working prototype. Taking ARIA into a real industrial deployment surfaces a different set of concerns than building it does — most of them about trust, not capability.

Why this matters more in oil & gas (and other regulated industries)

The data ARIA touches is not ordinary enterprise data. P&ID drawings reveal plant topology and safety-critical interlocks. Equipment failure histories are tied to incident investigations that may be under active legal or regulatory hold. Maintenance records can expose operating envelopes, proprietary process conditions, and personnel identities. Stakeholder emails frequently contain unredacted PII and, in offshore or international operations, data that crosses sovereign jurisdictions.

A leak of any of this is not an "oops, reset the password" event — it can be a reportable incident under PSM (29 CFR 1910.119), a chain-of-custody break in an ongoing investigation, an export-control violation (ITAR/EAR for some equipment specs), or a GDPR / data-residency breach. The same considerations apply, with different acronyms, in pharma (GxP, 21 CFR Part 11), healthcare (HIPAA), finance (SOX, GLBA), utilities (NERC CIP), and defence (CMMC, ITAR).

For these environments, "the model provider has a privacy policy" is not enough. The deployment has to assume the data never leaves customer-controlled boundaries, and the audit trail has to be good enough to defend in a regulatory or legal proceeding.

Deployment posture

• Self-hosted backend in the customer's VPC, with Anthropic accessed over a private endpoint where available
• Managed-agent sessions configured with zero data retention (ZDR) contracts so prompt + tool-use payloads are not retained by the model provider
• Outbound email sent from a customer-owned domain with SPF, DKIM, and DMARC enforced — the agent must never look like spoofed mail
• Inbound webhooks (Resend, Retell, Twilio) signature-verified before any session resume; unsigned or replayed payloads are rejected and logged

Data in motion and at rest

• TLS 1.2+ on every external hop (Anthropic API, Resend, Retell, Postgres)
• Postgres at-rest encryption (Neon / customer-managed RDS) plus column-level encryption for any PII stored in contacts or thread bodies
• Secrets managed through a KMS / vault, not env files in production
• File uploads (P&IDs, sensor logs) scoped to a single session and purged on report archive

Access and audit

• SSO + RBAC on the operator UI; the operator can steer or interrupt sessions but cannot read another tenant's data
• Full audit trail of every agent action: tool calls, outbound messages, status transitions — exportable for regulatory review (PSM, OSHA 1910.119, equivalents)
• Stakeholder-facing email and call logs retained per the customer's record-retention policy, not ours

Human-communication safety

• Rate limits and a per-stakeholder daily cap so a misbehaving agent can't flood an inbox or escalate inappropriately
• Phone-call recording flagged at the start of every call to comply with two-party-consent jurisdictions
• Allowlist of domains and numbers the agent is permitted to contact — no open-ended outreach
• Operator approval gate on the first message to any new stakeholder, with the gate auto-relaxing once the relationship is established

Compliance surface

• The architecture is compatible with SOC 2, HIPAA (healthcare), IEC 61511 / OSHA PSM (process safety), NERC CIP (utilities), and 21 CFR Part 11 (life sciences) expectations for safety- and integrity-critical analyses, but a real deployment would require formal controls and an audit
• For oil & gas specifically: data residency configurable per region (US / EU / Middle East / APAC) so operator data never crosses a sovereign boundary it isn't allowed to; export-control review on any equipment specifications shared over outbound channels
• Output reports are reviewed and signed by a human engineer of record — ARIA proposes; the engineer approves
• Every agent action is reproducible from the audit log: same inputs, same tool calls, same outputs — a property regulators increasingly expect from AI systems making safety-relevant recommendations

Plenty of work remains in the space ARIA opens up:

• Verification of human-supplied context. When a stakeholder gives the agent an answer, how confident should the agent be? Cross-checking responses against historical records, other stakeholders, or sensor data is mostly unsolved.
• Conflict resolution. Two stakeholders give contradicting answers. Whose context wins, and on what basis? Today this falls back to escalation; it should be a first-class reasoning step.
• Stakeholder modelling. A senior engineer's reply carries more weight than a junior's; a 3-day-late reply means something different from a same-day one. The agent should learn these patterns per-person, per-org.
• Cross-session memory. Long-idle sessions today can't easily share what they've learned with parallel sessions or future ones. A persistent organisational memory layer above sessions is the next architectural step.
• Cost and observability on idle sessions. Knowing the state of a 36-hour-idle session without replaying history is currently awkward. Better introspection primitives from the managed-agent layer would help.
• Domain adaptation. Each new industry brings its own document types, regulatory templates, and escalation hierarchies. A clean way to swap the domain layer without rewriting the agent core is an open design question.
• Real-time write-back. ARIA currently produces reports. The next step is closing the loop — writing findings back into the CMMS, work-order system, or maintenance schedule, with the same human-approval gates.

Most of these aren't bugs in this implementation; they're problems the field hasn't solved yet. Human-in-the-loop at industrial scale is new territory.

The goal is a single managed agent session that receives context from every channel a human might use — email, phone, SMS, Slack, Zoom transcript, Teams chat — and synthesises it all into a coherent analysis. No channel switching. No context loss. The agent adapts to the human, not the other way around.

This is what human-in-the-loop means at industrial scale: not a human clicking "approve" in a UI, but an agent that can navigate real human communication workflows, at real human timescales, to surface knowledge that no system has ever captured.