Agents
Governed identities, not anonymous API callers
What Aintlijx controls
Production AI needs more than model access. Aintlijx governs the operational primitives around execution: who can act, what tools are allowed, how workflows run, what credentials resolve, what it costs, and what evidence is preserved.
Workflows
Structured execution with policy gates
Tools
Registered capabilities with scoped access
Identity & IAM
Users, service accounts, agents, roles
Tenancy
Organization, workspace, environment boundaries
RBAC
Product-scoped permissions
Secrets
Vault-backed credential resolution
Observability
Correlation across services and execution
Audit
Evidence-oriented execution records
In active testing today
The core platform is runnable in real environments and being validated with design partners. This is in active testing—not self-serve general availability.
- Identity, authentication, and service-account foundations
- Agent and composer execution paths with correlation-aware observability
- Workflow and tool-gateway integration patterns
- Tenant and workspace context propagation (enforcement expanding)
- Cost and prompt-log instrumentation on LLM paths
Gaps remain in tenancy enforcement breadth, certification, and self-serve onboarding—we label maturity honestly rather than overclaiming general availability.
Platform layers
| Layer | Role |
|---|---|
| Experience | Customer workspace and product surfaces on shared governance |
| Control plane | Agents, workflows, composer, policy, and orchestration |
| Execution | Tool gateway, sandboxes, credential resolution |
| Identity & tenancy | IAM, organization context, product-scoped RBAC |
| Data & evidence | Audit, prompt logs, cost metering, trace correlation |
| Infrastructure | Kubernetes-native services, secrets, networking |
Control plane stack
Services are designed to compose: identity establishes who is acting; tenancy scopes what they can touch; agents and workflows execute with tool and credential policy; observability and audit capture what happened end to end.
One control plane — execution and governance converge.
Governed execution loop
Intent → Plan → Policy → Execute → Observe → Audit
Every meaningful action should be traceable: who requested it, which identity executed it, which tools were used, what policy applied, what it cost, what changed, and what evidence was produced.
Tenant and workspace model
Aintlijx is designed for both dedicated single-tenant environments and multi-tenant platform operation. Organization context propagates across HTTP, service-to-service calls, and async workers—resolved once, verified at the boundary, enforced in data paths.
Workspaces represent dev or operational environments within an account. Product surfaces inherit the same boundaries rather than inventing per-app tenancy.
Agents are governed identities
Agents are not opaque model calls. They run as identities with tool permissions, credential policy, cost budgets, and audit obligations—the same discipline expected of human operators and service accounts.
Product-level RBAC
Roles are scoped to products, workspaces, workflows, tools, secrets, and audit visibility—not one global admin for everything.
| Role | Typical scope |
|---|---|
| Platform admin | Organization settings, members, billing visibility |
| Security admin | Secrets, policies, tenant isolation, access reviews |
| Product admin | Product surface configuration and entitlements |
| Agent operator | Run and monitor agents within policy bounds |
| Workflow approver | Reviews and approves sensitive execution paths |
| Developer / builder | Workspace access, tool usage, workflow authoring |
| Auditor | Read-only access to execution and audit evidence |
Builder experience vision
The builder path is designed around structured progression: clarify intent, produce a plan, pass policy checks, execute with approved tools, observe outcomes, and preserve audit evidence. This is product direction—not a claim that every step is finished today.
Platform maturity
Aintlijx control plane
In active testingObservability & governance
In active testingCustomer workspace
In developmentProduct surfaces
PlannedIn active testing — built enough to test seriously; not broadly released. In development — being actively built; not yet testable as a public product. Planned — on roadmap; not implemented yet.