Create, Own, Version, and Bind an Agent

Enterprise problem: If an agent is treated as a file owned by its creator, sharing or publishing it can leak the creator's private authority, strand production when that person leaves, or mutate approved behavior without review.

Whole-course context: This is the create-and-generate entry point of the full customer journey: a customer turns intent into an owned agent record, immutable version, declared capability requirements, and reviewable deployment plan before any team, credential, or runtime binding exists.

Today’s slice: We design draft collaboration, durable ownership, immutable versions, declared sharing modes, team deployment plans, and abstract capability bindings in the provider control plane; later days activate identity, credentials, runtime access, public visibility, revocation, redeployment, and rollback.

End-of-day evidence: A reviewer receives an ownership-transfer trace, immutable manifest digests, Marketing-versus-Sales deployment proofs, public-boundary denials, and revoke/rollback events tied to exact actors, resources, scopes, environments, timestamps, and IDs.

Still unsolved: Run authorization, per-tool connector decisions, capability-token minting, agent-to-agent delegation, and long-running revocation freshness are deliberately deferred.

Thesis: An enterprise agent is not a portable copy of its creator; it is durable logic that becomes safe to share only when ownership, immutable behavior, and environment-specific authority are separate records.

The smallest complete mental model has three boxes: define who owns the agent, freeze what it may require, then bind those requirements independently for each destination. Northstar's HelixWorks Supplier Onboarding Agent can therefore keep one reviewed v17 while Procurement and Compliance receive different resources and neither inherits Alice's authority.

The customer outcome is a reliable, reviewable implementation of 01 create own version and bind an agent. This day introduces the mechanism before policy detail and evidence review; it does not repeat the same customer stories in prose, tables, and diagrams.

Authorization policy service owns decisions; the connector/runtime gateway owns enforcement. Compute: API and isolated worker processes. Storage: PostgreSQL is authoritative for grants and state; Redis is a versioned cache; vault owns secrets; object storage retains redacted evidence only.

Implement the day’s boundary with a current, explicit decision before privileged compute or a downstream call. Bind every effect to a tenant, subject or workload, deployment, resource, and short-lived evidence ID; a cache or model response never grants authority.

The hard design choices appear when portability, operational continuity, and least privilege pull in different directions; hiding those choices produces either fragile automation or authority leakage. Use the trade-offs below to decide which boundary must remain fixed and which can vary per deployment.

A design is incomplete when it names records but cannot prove their transitions; the consequence is a schema that looks secure while product actions bypass it. Implement the Acme path in dependency order and attach an observable test to every state change.

1. Create agent_campaign_launch as a private draft with Alice as creator and Marketing as proposed durable owner.
2. Add explicit collaborator grants; verify agent.run does not imply agent.edit, agent.deploy, or sensitive-log access.
3. Canonicalize the manifest, publish v17, and persist its content digest, tests, approval, and declared capabilities without credentials.
4. Attempt a direct edit of v17; require published_version_mutation, then create v18 and prove v17 remains unchanged.
5. Create separate Marketing and Sales deployment records; bind every required capability to a resource owned by the target team.
6. Probe each deployment for its own resource allow and the other team's resource deny; seal actor, resource, scope, precondition, expected result, observed result, environment, timestamp, binding digest, decision ID, and trace ID.
7. Offboard Alice, rotate the steward, revoke her personal grants and connector references, and confirm the Marketing deployment remains healthy only through team-owned authority.

Minimum acceptance matrix:

The model only becomes useful when Acme tests one real lifecycle rather than approving diagrams; otherwise the first offboarding or cross-team share will discover the missing boundary in production. Build the HelixWorks Supplier Onboarding Agent ownership/version/deployment fixture, run the six acceptance probes above, and block release unless the evidence is complete.

The claim is falsified if any probe can mutate v17, keep Alice's personal authority after offboarding, resolve a Marketing resource from Sales, or reach an enterprise connector anonymously. The practical deliverable is one sealed, observable evidence bundle containing the two immutable version digests, separate Marketing and Sales binding digests, all allow/deny decision IDs, the ownership-transfer event, and the final healthy deployment probe.

Northstar implements the recurring example as a governed supplier-onboarding blueprint. Read services/control-plane/src/domain/blueprint.ts:

const immutableDefinition = {
  tenantId,
  projectId: command.projectId,
  blueprintId: command.blueprintId,
  version: command.version,
  workflow: command.workflow,
};
const digest = `sha256:${createHash('sha256')
  .update(canonical(immutableDefinition))
  .digest('hex')}`;

The declared intent is “approve these exact supplier checks.” Node interprets the TypeScript; the control-plane use case stores a frozen definition and digest; CPU computes the hash and storage retains it; BlueprintApproved.v1 is the observable proof. The domain function has one responsibility (SRP), while injected store and outbox ports keep persistence and publication outside it (IoC/DI). Canonicalization is shared (DRY), and the HTTP controller remains the MVC boundary rather than owning approval rules.

pnpm --filter @helixworks/control-plane test

The claim is falsified if reordering object keys changes the digest, changing one required approval does not change it, or an approved object can be mutated. Add those three probes before treating the digest as a release identity.