Waypoint™

Waypoint™ Worker, Agent and Capability Model

1. Purpose

Waypoint™ must assign work based on what a worker is capable and authorized to do rather than hard-coding work to a specific AI product or human role.

This specification defines the generic Worker model and the concepts required for allocation, execution, governance, capacity, and reporting.

2. Worker abstraction

A Worker is an entity capable of performing project work.

Worker
├── Human
├── AI Agent
├── Agent Team
├── Automation
└── External System

All worker types share common scheduling and governance concepts while supporting type-specific execution behavior.

3. Worker identity

A worker record should include:

  • stable worker ID;
  • worker type;
  • display name;
  • status;
  • owner/provider;
  • capability profile;
  • permissions/policy profile;
  • execution environments;
  • capacity/concurrency;
  • cost model where available;
  • availability;
  • reliability/performance history;
  • supported interfaces.

Credentials should not be stored directly in the worker record; use secure credential references.

4. Capability

A Capability is a normalized statement of work a worker can perform.

Examples:

software.nextjs
software.typescript
data.sql-server
data.fabric
cloud.azure
iac.terraform
quality.regression-testing
security.review
docs.technical-writing
delivery.vercel
delivery.azure

Capabilities should be hierarchical/taggable and extensible.

5. Capability proficiency

A worker's capability may include:

  • level/proficiency;
  • verified/unverified status;
  • evidence/source;
  • allowed autonomy level;
  • environment restrictions;
  • recency;
  • success history.

Waypoint™ should not assume that declaring a capability proves competence.

6. Skills versus capabilities

A Capability is used for planning/allocation.

A Skill is reusable procedural knowledge describing how work should be performed.

Example:

  • Capability: software.github-pull-request
  • Skill: organization's PR procedure, template, validation checks, branch policy, documentation expectations.

A worker may possess a capability and be supplied one or more skills at execution time.

7. Tools

Tools are actionable interfaces available to workers.

Examples:

  • GitHub API;
  • Jira API;
  • terminal;
  • browser;
  • Azure API/CLI;
  • database connection;
  • Vercel API;
  • testing framework.

A capability may require one or more tools.

Tool availability and authorization must be evaluated independently from capability.

8. Execution environment

Workers may operate in one or more environments:

  • local workstation;
  • managed cloud worker;
  • container;
  • VM;
  • development sandbox;
  • CI runner;
  • cloud shell;
  • remote agent platform.

Environment metadata should include:

  • supported tools;
  • network boundaries;
  • filesystem/workspace model;
  • credentials available;
  • data classifications allowed;
  • lifecycle/cleanup policy.

9. AI Agent

An AI Agent is a Worker whose execution is driven by an AI model/runtime.

Agent metadata may include:

  • provider/runtime;
  • model configuration;
  • reasoning/tool limits;
  • context limits;
  • supported tools;
  • agent instructions;
  • skills;
  • autonomy policy;
  • cost model;
  • concurrency;
  • timeout;
  • heartbeat behavior.

The core domain must not depend on a particular AI vendor.

10. Agent profile versus agent instance

Waypoint™ should distinguish:

Agent Profile — reusable definition of capabilities, tools, instructions, constraints, and runtime configuration.

Agent Instance — a concrete execution worker created from a profile.

This permits pools and ephemeral workers.

11. Agent teams

An Agent Team is a Worker composed of multiple agents coordinated toward one authorized work package.

A team may contain roles such as:

  • lead;
  • implementer;
  • tester;
  • reviewer;
  • specialist.

The team exposes an aggregate capability profile to allocation.

Internal subagent work must remain within the parent's authorization boundary.

12. Human workers

Human workers should support:

  • capabilities;
  • availability;
  • capacity;
  • team/organization;
  • approvals they may grant;
  • work preferences;
  • notification endpoints.

Sensitive HR/performance information should not be inferred or collected unnecessarily.

13. Automation workers

Automation workers represent deterministic systems such as:

  • CI jobs;
  • deployment pipelines;
  • scheduled processes;
  • validation jobs;
  • scripts.

They may have near-zero reasoning but still participate in dependencies, execution, evidence, and capacity.

14. External-system workers

Some work is effectively delegated to an external managed system.

Examples:

  • managed build service;
  • cloud provisioning service;
  • external approval system.

Waypoint™ should track request, state, completion, and evidence even when it does not control the internal execution.

15. Work requirements

A work item may declare:

  • required capabilities;
  • optional/preferred capabilities;
  • prohibited worker types;
  • human-required flag;
  • required tools;
  • required environment;
  • data/security classification;
  • autonomy level;
  • review requirements;
  • expected duration/effort;
  • concurrency constraints.

16. Matching and allocation

Worker matching should consider:

  1. hard capability requirements;
  2. authorization/security;
  3. tool/environment availability;
  4. current availability;
  5. capacity/concurrency;
  6. stream/workspace constraints;
  7. proficiency/history;
  8. cost;
  9. expected completion time;
  10. preferred worker/profile;
  11. reviewer capacity.

Hard constraints must be satisfied before optimization preferences.

17. Allocation modes

Waypoint™ should support:

  • planned assignment;
  • runtime assignment;
  • worker pull;
  • manual assignment;
  • team assignment;
  • reassignment;
  • fallback worker.

The plan may forecast allocation while Execute makes the final runtime reservation.

18. Capacity

Capacity differs by worker type.

Human capacity may be hours/timebox.

AI capacity may be:

  • concurrent sessions;
  • provider quota;
  • execution slots;
  • budget;
  • token/compute constraints.

Automation capacity may be runner slots or provider limits.

Waypoint™ should normalize enough capacity information to schedule work without pretending all worker types are equivalent.

19. Cost

Where available, worker cost should support:

  • estimated cost;
  • actual cost;
  • budget threshold;
  • cost per run/hour/token/action;
  • project/stream allocation.

Cost may influence allocation but must not override hard capability/security requirements.

20. Autonomy levels

Waypoint™ should support configurable autonomy classifications, for example:

  • A0 Observe — read/analyze only;
  • A1 Propose — produce recommendations/artifacts but no governed mutation;
  • A2 Execute bounded non-production work;
  • A3 Execute governed changes with automated gates;
  • A4 Execute high-impact/production actions only with explicit gate approval.

Exact policy should be configurable.

21. Permissions

Authorization should be least-privilege and action-specific.

A worker may be capable of Azure deployment but only authorized for a development subscription.

A worker may create a PR but not merge to production.

Permissions should consider:

  • project;
  • action;
  • tool;
  • environment;
  • resource;
  • data classification;
  • lifecycle stage;
  • approval state.

22. Worker health and reliability

Waypoint™ should track operational signals such as:

  • availability;
  • heartbeat;
  • run success/failure;
  • timeout;
  • retry frequency;
  • average duration;
  • quality failures.

Historical metrics may improve allocation but should not become opaque, permanent scoring without governance.

23. Worker registry

The Control Plane should provide a Worker Registry supporting:

  • profile management;
  • capability registration;
  • environment/tool associations;
  • availability;
  • capacity;
  • permissions;
  • health;
  • cost;
  • versioning.

Changes to high-impact permissions should be audited.

24. Capability registry

Capabilities should be centrally normalized so plans do not accumulate arbitrary inconsistent labels.

The registry should support:

  • canonical identifier;
  • display name;
  • description;
  • hierarchy/category;
  • aliases;
  • prerequisites;
  • compatible tools;
  • deprecation/replacement.

Project-specific capabilities may be added under governance.

25. Skills registry

Reusable procedural skills should be versioned.

A skill may define:

  • purpose;
  • trigger/use cases;
  • prerequisites;
  • procedure;
  • required validation;
  • output expectations;
  • policy constraints.

Execution should record which skill version was supplied when material to reproducibility.

26. Reporting

The reporting API should expose:

  • worker inventory;
  • capability coverage;
  • capacity;
  • allocation;
  • utilization;
  • queue depth;
  • run counts;
  • success/failure;
  • estimate versus actual by worker/profile/capability;
  • cost;
  • quality/rework;
  • health.

Reporting must respect privacy and authorization.

27. Initial completion criteria

The model is sufficient for initial Waypoint™ when it supports:

  1. humans and AI agents;
  2. reusable agent profiles and concrete instances;
  3. normalized capabilities;
  4. tools/environments;
  5. capability-based matching;
  6. capacity/concurrency;
  7. authorization/autonomy;
  8. reservations and assignments;
  9. health;
  10. execution actuals;
  11. extensibility for agent teams, automations, and external systems.