request = {
"agent": "support-summary-agent",
"process": "summarize",
"dataset": "customer_support_logs",
"mannequin": "external_llm_api",
"delegated_by": "user_4821"
}
coverage = evaluate_policy(request)
if coverage.allowed:
route_to_execution(coverage.execution_environment)
else:
increase AuthorizationError(coverage.motive)
The coverage engine right here evaluates dataset classification, mannequin approval standing, geographic processing guidelines, and the delegation chain that initiated the request. Which may imply redirecting the duty to an inner inference cluster as a substitute of a public API endpoint, or blocking the request if no compliant execution surroundings exists. From the agent’s perspective, the duty nonetheless executes. The orchestration layer ensures it runs in an surroundings that satisfies enterprise coverage.
Why ontologies are load-bearing infrastructure
For the orchestration layer to make good selections, it must do greater than label information. It wants to know how the entities concerned in a request relate to one another, and motive over these relationships to find out what’s allowed.
Think about the client assist transcript instance once more. Metadata tells you the dataset incorporates PII (personally identifiable info). An ontology lets the system motive throughout a related chain: the duty operates on a dataset containing private information; that information is ruled by GDPR; the group’s coverage requires processing inside an permitted EU surroundings; the chosen mannequin runs exterior that boundary. From these 4 related information, the orchestration layer can infer the request should be rerouted or blocked. The system reasoned over the relationships quite than matching towards a hardcoded rule tied to a selected dataset.
