Jeffrey Bradshaw and KAoS: Policies for Governing Autonomous Agents
Jeffrey Bradshaw and the KAoS team treated autonomy as something that should be bounded by explicit machine-readable policies governing authorization, obligations, domains and agent behavior.
KAoS began from the problem of making autonomous agents operationally governable
Autonomous agents promise flexible behavior, but operational systems need limits. Jeffrey Bradshaw and collaborators developed KAoS in the 1990s as an agent architecture and later as a policy and domain services framework for controlling what agents, people and software resources may do. A 1997 account described KAoS as an effort toward an industrial-strength open agent architecture.[1] The project asked a question that has become more urgent with modern agents: how can autonomy remain useful when organizations need explicit, enforceable rules around security, coordination and responsibility?
Domains represented organizations explicitly
A domain can model a team, department or dynamic mission group, allowing policies to follow organizational membership rather than individual hard-coded identities.
Domains gave policy a model of organizational structure
KAoS domain services organize agents, people and resources into domains and subdomains that can correspond to organizations, teams or administrative groups. Later KAoS documentation describes nested domains whose membership can span machines and change over time.[2] This organizational layer matters because policies are rarely universal. A rule may apply to one mission team, role or resource class but not another. Domains let governance follow organizational structure without hard-coding every agent identity into every rule.
Authorization and obligation answer different governance questions
Authorization asks whether an action may occur; obligation asks whether an action must occur. Reliable governance often needs both kinds of rule.
Authorization and obligation policies bounded what agents could do
KAoS policy services distinguish authorization policies—what an actor is permitted or forbidden to do—from obligation policies—what an actor is required to do under specified conditions. Research on KAoS policy management for semantic web services showed how such rules could constrain workflows and enforce additional obligations at runtime.[3] The distinction is powerful because safety is not only about blocking actions. An autonomous system may also be required to log, notify, request approval or perform a compensating action when a certain event occurs.
Semantic policy generalized across classes
Ontology reasoning lets one policy apply to every member of a defined class and automatically extend to recognized subclasses or related concepts.
Ontologies made policy vocabulary extensible and machine-readable
KAoS later adopted DAML and then OWL ontology languages to represent policy concepts. The framework could describe classes of agents, actions, resources and contexts using shared semantic vocabularies rather than enumerating individual cases. Bradshaw’s IHMC profile describes KAoS as an ontology-based policy and domain services framework built on W3C standards.[4] Ontologies make policy extensible: a new subclass can inherit rules automatically if the reasoning system recognizes that it belongs to an already governed category.
Conflicts must be resolved before enforcement
A rule set can contain contradictions. A policy framework therefore needs analysis tools that identify conflicts and determine which rule should dominate in a given context.
Policy conflict detection turned governance into a reasoning problem
Machine-readable policy creates its own reasoning challenges. Two rules can conflict, a permitted action can trigger a forbidden consequence, or a new class definition can alter which policies apply. KAoS therefore included analysis and conflict-resolution mechanisms in addition to enforcement. The AAMAS work on representation and reasoning for KAoS emphasized specifying, managing, resolving and enforcing policies in organizational contexts.[5] Governance became a computational reasoning problem rather than a set of hard-coded if-statements scattered across applications.
KAoS expanded from software agents into web services, grids and human-machine teams
KAoS expanded beyond its original agent architecture into grid computing, semantic web services, network management, mobile-agent systems and human-agent-robot teams. IHMC describes deployments and research in cybersecurity and mixed human-machine coordination where policies constrain information sharing, actions and teamwork.[4] This expansion demonstrated that the policy abstraction was broader than one agent platform. Any distributed autonomous system benefits from a layer that can state and enforce rules independently of application code.
Adjustable autonomy connected policy to trust
Bradshaw’s later work connected KAoS with adjustable autonomy: systems should be capable of acting independently, but their permitted ‘wiggle room’ can change with context, risk and human oversight. Research on trustworthy adjustable autonomy argued that explicit policy can bound agent action while preserving enough freedom for useful initiative.[5] This framing avoids the false choice between total automation and constant human micromanagement. Autonomy becomes a governed operating region whose boundaries can shift.
Why KAoS belongs in the history of multi-agent systems
KAoS belongs in multi-agent history because it made governance a first-class part of agent architecture. Bradshaw and collaborators recognized that powerful autonomous systems need explicit policies for who may do what, under which organizational context and with what obligations.[2][3] Modern AI-agent safety discussions revisit the same structure through permissions, tool policies and approval gates. KAoS showed decades earlier that autonomy becomes deployable when constraints are represented, reasoned about and enforced systematically.
KAoS is especially relevant to contemporary tool-using AI because tool permissions are policy. Granting an agent access to a shell, database or messaging system creates authority that must be scoped. Modern implementations may use capability tokens or allowlists rather than OWL ontologies, but the architectural principle is the same: agent intelligence should be separated from an external governance layer that can restrict, audit and revise what the agent is allowed to do.
The broader significance of this work is that multi-agent systems require explicit machinery for relationships among decision makers. Communication, coordination, incentives, task structure, learning or governance may dominate depending on the problem. The pioneers in this batch helped turn those relationships into concrete software abstractions that could be implemented, analyzed and compared rather than left as informal assumptions.
Works Cited
- 01
- 02
- 03
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead