Click to enlarge Provider runtime overview
The Provider keeps auth, Context, typed domain operations, thin Skill adapters, and downstream execution inside one explicit boundary.
An integration architecture for enterprise systems, not just tool connectors.
AtlasClaw turns integrations into provider contracts so IM, web, embedded apps, and webhook AI integration calls can reach one multi-user AI agent layer. Configured Providers can also map Enterprise System pages to live business objects and governed actions.
Provider runtime
Start with the provider runtime architecture.
This diagram shows how configuration schema, auth and Context, thin Skills, typed domain operations, and downstream execution fit inside the Provider boundary.
Click to enlarge Provider runtime overview
Close preview The Provider keeps auth, Context, typed domain operations, thin Skill adapters, and downstream execution inside one explicit boundary.
Why this architecture
Integration is where enterprise AI either becomes reliable or falls apart.
AtlasClaw is designed so integrations stay explicit. Providers hold system contracts, Skills stay executable and narrow, and the core keeps one reusable orchestration model for governed execution.
Provider contracts, not loose tool wrappers
Each provider-based integration owns its configuration schema, auth model, reusable domain rules, thin adapters, and references instead of leaking them into the core.
Skills become controlled system verbs
Skills are the governed execution boundary between user intent and target-system action.
One agent layer across many access channels
IM, web, embedded modules, and webhook callers can all reach the same AtlasClaw execution model.
Existing systems gain AI without being rebuilt
Traditional products can call AtlasClaw as a webhook AI integration layer instead of implementing their own agent stack from scratch.
Providers define page Context
Deterministic routes map an Enterprise System page to its current domain object, available actions, and the Provider capability that understands it.
Execution path
From access channel to governed system action.
The integration model stays readable because every hop has a clear responsibility boundary.
- Users or systems reach AtlasClaw through IM, web UI, embedded panels, or webhook entrypoints; an Enterprise System can also publish normalized page changes for a floating assistant.
- The agent engine selects provider-qualified skills and builds the execution plan.
- Providers translate intent into target-system operations with the right auth and data boundaries.
- Enterprise systems remain the operational source of truth for permissions, workflow state, and audit.
Integration method
Provider model
A Provider is a self-contained integration package: metadata and configuration schema, auth conventions, reusable domain code, thin Skill adapters, optional page Context, and reference material. Core loads Providers from `providers_root` and exposes provider-qualified Skills for runtime dispatch.
- Providers keep platform-specific auth and workflow logic out of the core.
- Reusable API and business operations live in an importable Provider package while Skills stay readable, explicit, and thin.
- Explicit callable entrypoints receive scoped runtime Context without duplicating domain rules in protocol adapters.
- Webhook and channel access can target the same provider-qualified execution layer.
Architecture value
What the enterprise gets
This model is not just about connecting APIs. It creates one governed AI execution layer above existing systems.
- One multi-user agent layer instead of repeated personal integrations.
- A reusable way to add AI capability into existing enterprise products.
- Clearer boundaries for access control, audit, and system ownership.
Enterprise domains
One provider model across the enterprise stack.
The same provider-based integration architecture can be applied across operational systems, business systems, developer systems, SmartCMP, and Jira.
SmartCMP
A versioned SmartCMP Provider reference with typed domain operations, page-aware requests and approvals, governed resource lifecycles, Security workflows, and read-only editor assistance.
View referenceJira
A Jira provider example for issue operations, provider-qualified skills, and enterprise agent wiring patterns.
View referenceITSM systems
Service and request workflows can be executed through governed providers instead of ad hoc tool calls.
Monitoring and alerting systems
Alerts, incidents, and operational diagnostics can be exposed as explicit skills.
OA, CRM, HR, and finance systems
Business-side workflows can gain AI coordination while keeping system-side permissions and approvals intact.
GitHub and engineering tools
Development workflows can be integrated as provider domains instead of bolted-on personal-agent tools.
Build next
Read provider docs Build your own provider
Use the SmartCMP and Jira examples as reference points, then package your own platform with provider metadata, configuration schema, reusable domain operations, and thin Skill adapters. Contributions of new system integrations are welcome in the atlasclaw-providers repository.