Framework freedom should not create governance fragmentation
In real organisations, one team chooses CrewAI, another builds a graph, a third adopts a Microsoft runtime, and a fourth writes a custom worker. Without a common control model, the same business action can be governed differently—or not at all—depending on which framework happened to execute it.
AgenticDome keeps the policy meaning consistent while respecting the framework’s actual shape. Hooks, runner wrappers, secured tools, graph nodes, callbacks, middleware, and core-client calls all carry the same essential context: tenant, actor, agent, purpose, action, arguments, delegation, session, and outcome.
What changes when AgenticDome is in the path
Developers attach the adapter at the framework’s real assembly and execution points. The protected path screens supported input, authorizes tools and handoffs before execution, reviews configured output, and sends a consistent decision record to the tenant’s assigned AgenticDome runtime—without requiring the organisation to standardize on one agent framework.
Why platform teams standardize on AgenticDome
The strategic value is portability of security policy. Framework teams keep their preferred development model; the organisation keeps one way to describe authority, delegation, sensitive output, and evidence.
Preserve developer choice
Use framework-shaped adapters rather than forcing every team into one orchestration platform or a generic proxy that cannot see local execution context.
Make policy portable
Apply the same tenant meaning to a refund, export, customer lookup, or delegated action even when different frameworks execute it.
Verify agent handoffs
Treat manager-to-specialist delegation as an authorization event bound to the intended tool and arguments, not as implicit trust between agents.
Unify operational evidence
Give security and governance teams consistent actor, agent, session, action, verdict, and correlation fields across supported runtimes.
A low-friction path from evaluation to live policy
Every supported Python integration can first run a network-free allowed and blocked scenario with no account. Developers then install only the framework extra they need, attach the documented boundary, and connect it to a managed sidecar in the selected supported geographic region or a contracted Sovereign runtime inside the customer-controlled environment.
How AgenticDome creates the control point
1. Prompt ingress
Use the framework’s supported hook, runner, node, callback, or explicit client boundary.
2. Tool selection
Authorize the real tool name and sanitized arguments before local execution.
3. Delegation
Authorize and verify documented manager/specialist handoff paths where used.
4. Output and stream
Review the supported result or stream before customer delivery or reuse.
5. Evidence
Send the same tenant, actor, agent, purpose, and correlation context to the assigned sidecar.
What this changes for real teams
One posture across independent teams
“Teams should be free to choose frameworks without inventing a new security contract for each one.”
AgenticDome contribution: Framework-shaped adapters share the AgenticDome client and tenant runtime contract, so actor, purpose, tool, delegation, output, and evidence fields retain the same meaning across supported stacks.
Protect the transition, not only the destination
“We are moving from AutoGen to Microsoft Agent Framework while legacy workflows remain live.”
AgenticDome contribution: Use the documented adapter for each deployed runtime during the transition, keeping policy and evidence consistent while teams migrate at an operationally safe pace.
Generated code still meets an action boundary
“A model-generated program can call tools and services with more impact than ordinary text.”
AgenticDome contribution: The smolagents integration protects documented tool and generated-code paths before execution and reviews output, while the host retains sandbox, egress, filesystem, process, and credential isolation.
The risks this helps contain
| Risk | Why it matters | Public AgenticDome control |
|---|---|---|
| Framework-specific bypass | A protected agent can still call an unwrapped tool or raw runner through another path. | Attach at the documented assembly point and remove alternate raw executors, runners, nodes, and clients. |
| Implicit handoff trust | A specialist may treat an upstream agent’s request as authority. | Use the adapter’s documented handoff authorization and specialist verification, bound to the actual tool and arguments. |
| Generated-code side effects | Code-generation agents can combine local execution and external tools. | Apply adapter checks at the tool/code boundary and retain sandbox, egress, filesystem, process, and secret controls. |
| Streaming disclosure | Partial output can escape before final-response review. | Use the documented streaming wrapper for that adapter; do not assume every framework has the same stream shape. |
| Version drift | Framework hooks and APIs change independently. | Pin supported ranges, run adapter tests on upgrade, and verify hook attachment at runtime. |
A practical path to production
Pick the exact adapter
Install only the extras needed and follow the guide for the runtime version in production.
Secure local tools
Treat the wrapper immediately before execution as the hard application boundary.
Propagate identity
Use stable session/run/trace IDs and authenticated human, workload, role, and scope context.
Run framework proof
Test allowed, blocked, handoff, output, stream, retry, and outage behavior for every deployed adapter.
Where this control ends
AgenticDome protects the Python boundaries the application attaches and invokes. It does not automatically instrument every framework object, remote hosted tool, provider-managed agent, generated process, or direct HTTP call. The SDK complements framework-native validation, human approval, secure coding, least privilege, sandboxing, egress policy, and observability.
Current lifecycle note
The supported-framework list and dependency ranges are versioned with each SDK release. Use the published package metadata and framework guides as the release-specific source of truth rather than relying on this category summary alone.