Configured first-class agents and workflows can run directly inside Atellagent.
Architecture
How Atellagent governs runtime execution.
Atellagent applies one governed runtime path across hosted and external agents, workflows, models, tools, channels, and enterprise APIs. The system evaluates actions in context before downstream effects proceed and preserves attributable evidence around the resulting outcomes.
Atellagent is a hosted platform plus a shared control architecture.
Customer-hosted runtimes can participate through bridge or SDK forms instead of bypassing the shared control path.
Identity, policy, and review evidence stay consistent across those runtime forms.
Three participation forms matter most.
- Atellagent owns the execution loop.
- Identity, policy checkpoints, and evidence stay first-party by default.
- This is the strongest built-in control posture.
- Atellagent governs the contract while translating to an external runtime.
- Existing customer-hosted runtimes can remain in place.
- This is the cleanest way to preserve existing execution while standardizing control.
- An existing process embeds governed outbound calls directly.
- The runtime keeps its own execution machinery while participating in Atellagent control contracts.
- This is useful when teams want direct integration without standing up a bridge process.
The control path links policy to real side effects.
governed runtime request
-> contextual policy evaluation
-> runtime execution controls
-> allow, deny, or narrow
-> attributable decision and outcome evidence
Autonomous requests enter through a governed entry point instead of calling downstream systems directly.
Actions are evaluated against runtime context rather than static permissions.
Approved actions remain controlled at runtime surfaces instead of relying only on earlier checks.
Decisions stay linked to resulting outcomes so review can follow the real control path.
Some failures only state can catch.
Individually safe actions can become unsafe in aggregate once workflow state and prior decisions are considered together.
Data, permissions, and meaning can change across multi-step execution paths, so reviewing one step in isolation is not enough.
Parallel checks can both pass unless reservation, coordination, and current state are explicit at decision time.
Deterministic policy and learned scoring serve different roles.
- Deterministic policy handles allow, deny, and control logic.
- Policy domains can be selected by action type and runtime context.
- Denies and platform invariants remain authoritative.
- ML detectors provide risk, model-security, or content-security signals.
- Those signals can inform review, narrowing, or response-side checks.
- The architecture supports both without collapsing one into the other.
Evidence is linked to the governing decision, not bolted on later.
Identity, policy path, runtime state, and detector signals remain attached to the governed decision.
The execution context stays attributable to the action and approval path that allowed it.
The system preserves what was requested, not just the side effect that eventually occurred.
Resulting external effects and response-side outcomes remain linked to the governing decision record.
Operators can inspect and reconstruct what happened without relying on disconnected logs or expiring raw traces alone.
The same control logic can span managed and customer-hosted execution.
- Hosted
- Private cloud
- On-prem
- Mixed hosted and external runtime participation
- Governed ingress and contextual evaluation
- Runtime execution controls
- Decision-linked evidence and review continuity
Want to review this boundary in your environment?
Book a technical review to walk through deployment boundaries, runtime forms, policy enforcement, identities, and evidence.