Packs and integrations
Packs for the work. Connectors for the systems. Room for everything else.
A pack is a versioned bundle of workflows, agent roles, controls, mappings, metrics and tests for one department or industry. Install one, plug in your systems, and start in observe mode.
What is in a pack
Six things, versioned together.
A Business Pack carries the work for one department or industry. A Control Pack carries the rules that sit over it. Both are versioned, so the difference between two releases is something you can read rather than something you have to ask about.
How Run uses a pack-
Workflows
The steps of the work itself: what gets picked up, in what order, and what counts as finished.
-
Agent roles
Which agents the pack brings, what each one is for, and the operating contract each one runs under.
-
Controls
The thresholds, segregation rules, purpose limits and approval rules over the pack’s actions, written as policy-as-code.
-
Mappings
How the pack’s controls and evidence line up with SOX and ICFR, ISO/IEC 42001, the NIST AI RMF, the EU AI Act and insurer questionnaires.
-
Metrics
Completion rate, human correction rate, exception rate and cost per completed workflow, reported from your own runs.
-
Tests
The cases a pack has to pass before it runs on your work, and again after every change made to it.
The catalogue
What exists, and what is planned.
Two statuses, used strictly. Available in pilot means you can run it in a 90-day pilot today. Planned means designed and not yet installable: no logo, no claim of support, and no place in your pilot until that changes here first.
The controls a pack brings with itDepartment packs.
| Business Pack | The work it takes on | Status |
|---|---|---|
| Finance operations | Overdue invoices investigated, follow-ups drafted, vendor-master changes and journal preparation, with Assure controls over each. | Available in pilot |
| Customer operations | Escalations prepared, refund and credit limits enforced, written commitments held until somebody approves them. | Available in pilot |
| Procurement | Supplier evidence collected, comparisons prepared, purchase controls applied before an order leaves. | Planned |
| Sales operations | Account reviews assembled from the CRM, the support queue and billing, with field updates proposed rather than made. | Planned |
| Engineering release readiness | Tests, approvals and open risks assembled for a release, with the gaps named rather than left out. | Planned |
Industry packs.
| Industry Pack | What it is designed for | Status |
|---|---|---|
| Longevity and health | Health-span plans, check-ins and follow-ups under a person’s oversight. JhiOn is the vertical platform built on this work. | Planned |
| Financial services | Operations work in a regulated firm, with the evidence mapped to the frameworks its auditors already use. | Planned |
| Insurance | Policy and claims operations under the same controls, with evidence shaped for an insurer’s own questionnaire. | Planned |
| Gaming operations | Player operations work: credits, adjustments and account actions, under limits and approvals. | Planned |
Connectors
The systems we are building towards.
Every connector below is Planned. They are named so you can check your own stack against the list; none of them is described as supported, and none carries a logo. Ayion Meru also reaches a system through an MCP server, an event feed or a signed change feed, which is how a pilot connects what it needs before a connector exists.
| Category | Systems | Status |
|---|---|---|
| ERP and finance | NetSuite, QuickBooks, Xero, Sage, Dynamics 365, Bill.com, Ramp, Stripe. | Planned |
| CRM and support | Salesforce, HubSpot, Zendesk, Intercom. | Planned |
| Agent platforms | Copilot Studio, Agentforce, OpenAI, Anthropic. | Planned |
| Channels | Slack, Teams, email. | Planned |
| GRC and security | AuditBoard, Workiva, Vanta, Drata, and SIEM export. | Planned |
Build your own
The same contracts as ours.
Custom actions, custom capture adapters and custom controls use the same contracts our own packs use. Nothing in a pack we wrote reaches an interface a pack you wrote cannot.
The contracts, in the architecture-
Custom actions
An action you write declares its schema, permissions, side effects and cost in the capability registry, exactly as ours do. Anything that has not declared them does not run.
-
Custom capture adapters
An adapter feeds actions from a system we have no connector for into the same ledger, and is asked for the same completeness statement.
-
Custom controls
Your own controls are written as policy-as-code against the same Control Blueprint format the packs use, and versioned the same way.
Planned A connector SDK and a pack development kit follow the ecosystem release.
See a pack in a pilot.
Ninety days on your systems, your agents and your work, starting in observe mode. You keep everything it produces.