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.

A single owner_user_id or has_access flag cannot express stewardship, production continuity, or permission separation, so it creates destructive ambiguity when people, teams, and releases change.

Use case ID	Actor	Customer job	Success outcome	Denial or recovery evidence
D01-UC-01	Agent builder and team administrator	Create a private draft, collaborate, then transfer durable ownership before production	Creator, collaborators, durable owning principal, and human steward are distinct; the team retains the published agent after the creator leaves	Creator deprovision removes personal grants and personal connector bindings while team-owned version and approved deployment remain operable
D01-UC-02	Release approver	Publish an immutable agent version with reviewable requirements	Version digest pins prompts, workflow, models, knowledge requirements, declared tools, argument constraints, approval rules, code, UI, schemas, and risk class	Any post-publication mutation changes digest and is rejected; a new version is required and the prior approved version stays addressable
D01-UC-03	Team deployment administrator	Share one definition with Marketing and Sales using separate deployment bindings	Each team receives explicit view/run grants and a deployment resolving abstract capabilities to its own resources, credentials, models, environment, and policies	A Sales run cannot resolve Marketing knowledge, channels, connectors, approvals, or credentials; Marketing remains a positive control
D01-UC-04	Security administrator and release operator	Publish a public-safe deployment, revoke an unsafe share, and roll back a release	Anonymous visibility is a distinct security class; revocation stops new access; rollback atomically selects a previously approved immutable version and binding set	Anonymous requests to enterprise connectors deny; revoked grants disappear; failed revision rolls back with old and new release IDs plus health evidence

Explicit permissions replace the boolean:

Permission	Customer meaning
agent.view	Discover the agent and see user-facing metadata
agent.run	Start an authorized deployment
agent.edit	Modify a draft, not a published version
agent.create_version	Freeze a reviewed release draft
agent.test	Exercise a release draft in a bounded environment
agent.deploy	Bind an immutable version to a team and environment
agent.share	Grant visibility or use without granting edit/deploy
agent.manage_connectors	Configure deployment bindings, separately from running
agent.transfer_ownership	Change durable owning principal through review
agent.delete	Retire or delete subject to deployment and retention constraints
agent.view_sensitive_logs	Inspect prompts, traces, or data that ordinary runners cannot see

The ability to run never implies access to system prompts, policy instructions, connector configuration, evaluation data, secret references, or internal implementation.

When all collaborators are called owners, neither the customer nor the platform can tell who may edit, approve, deploy, or recover an agent, and offboarding becomes either an outage or a data leak.

Story ID	Use case IDs	User story	Observable acceptance conditions
D01-US-01	D01-UC-01	As a team administrator, I want a published agent owned by the team with a named human steward, so that production survives the creator's departure without retaining that person's grants	Offboarding revokes creator collaboration and OAuth references; ownership query still returns team; replacement steward accepts transfer; production readiness probe remains healthy
D01-US-02	D01-UC-02	As a release approver, I want every deployed behavior represented by an immutable digest, so that reviewed logic cannot change behind an approval	Attempted edit to published v17 fails; creating v18 yields a new digest and approval state; deployment continues referencing exact v17 until promotion
D01-US-03	D01-UC-03	As a Sales deployment administrator, I want to install a shared campaign agent with Sales-owned bindings, so that shared workflow does not import Marketing's private resources	Sales catalogue entry resolves the common version but only Sales knowledge, Slack, task system, model policy, and approvals; probes for Marketing resources deny
D01-US-04	D01-UC-04	As a security administrator, I want public sharing, revocation, and rollback to be explicit operations, so that anonymous users cannot inherit enterprise access and unsafe releases can be contained	Public run exposes only public-safe capabilities; connector and privileged agent invocation probes deny; revocation blocks new runs; rollback restores prior version with immutable event trail

An agent's lifecycle separates creation facts from durable authority:

Private draft:
  may be creator-owned; explicit collaborators may view, edit, or test

Published agent:
  should be team- or organization-owned; immutable versions are addressable

Production deployment:
  references one immutable version; has a named steward; does not depend on the steward's account

An immutable version declares requirements, never live credentials:

apiVersion: agents.platform.example/v1
kind: AgentVersion
metadata:
  agentId: agent_campaign_launch
  version: 17
spec:
  model:
    capability: enterprise.text.reasoning
  knowledge:
    - capability: knowledge.brand-guidelines
      access: read
  tools:
    - capability: collaboration.messages
      operations: [message.read, message.post]
      constraints:
        channelClassification: [marketing]
        requireApprovalFor: [message.post]
  invocation:
    mayInvokeAgents: [agent.compliance-review]
  risk:
    dataClassification: internal
    externalSideEffects: true

The manifest excludes OAuth refresh tokens, private graph IDs, Slack workspaces, concrete Google accounts, production secrets, and API keys. Deployment resolves abstract requirements to environment-specific resources after policy review.

Sharing is unsafe when the product copies an agent and its environment together, because the receiving team may silently inherit secrets, data, or approvals that it never reviewed.

Flow ID	Use case IDs	Path	Trigger	Numbered steps	Terminal evidence
D01-FLOW-01	D01-UC-01	Recovery	Team administrator offboards the agent's creator	1. Resolve creator, durable owner, steward, personal grants, and personal connector references.<br>2. Revoke creator grants and credentials.<br>3. Preserve team-owned agent and qualifying team-managed bindings.<br>4. Assign a new steward through approval.<br>5. Run an authorized health probe.	Evidence records administrator, agent resource, ownership and revocation scopes, precondition creator inactive, expected continuity without personal authority, observed grant removals and healthy probe, environment, timestamp, transfer ID, and immutable offboarding-run ID
D01-FLOW-02	D01-UC-02	Denied	Builder attempts to edit published version v17	1. Load immutable state and content digest.<br>2. Reject mutation against published version.<br>3. Create release draft v18 from v17 through explicit action.<br>4. Recompute digest and require fresh tests and approval.<br>5. Verify production still points to v17.	Evidence records builder, version resource, agent.edit scope, precondition v17 published, expected mutation deny and new draft, observed results, environment, timestamp, old/new digests, and immutable decision ID
D01-FLOW-03	D01-UC-03	Happy	Sales administrator selects “Deploy to Sales” on catalogued v17	1. Check agent.deploy in Sales.<br>2. Create Sales deployment targeting Sales production.<br>3. Resolve each manifest capability to a Sales resource.<br>4. Validate model availability, operation constraints, credentials, and approval policy.<br>5. Probe Sales allow and Marketing-resource deny.	Evidence records Sales administrator, deployment and capability resources, Sales scopes, precondition v17 approved, expected Sales allow and Marketing deny, observed results, environment, timestamp, binding-set digest, deployment ID, and immutable probe-run ID
D01-FLOW-04	D01-UC-04	Recovery	Security administrator revokes a public share after a release health failure	1. Disable anonymous grant and stop new admissions.<br>2. Preserve in-flight policy and record containment decision.<br>3. Select prior approved version and binding-set digest.<br>4. Atomically repoint deployment.<br>5. Verify public-safe allow, enterprise-connector deny, and release health.	Evidence records security actor, public deployment resource, anonymous and rollback scopes, failure precondition, expected containment and healthy prior release, observed results, environment, timestamp, revoked grant, old/new release IDs, and immutable rollback-run ID

The sharing modes are separate product states:

Mode	Visible to	Runnable by	Binding rule
Private draft	Creator and explicit collaborators	Explicit testers only	Development bindings; creator OAuth never becomes portable
Specific users	Named principals	Principals with agent.run	Each runner's delegated connection or an explicitly approved team connection
Team deployment	Selected team	Current members with agent.run	Resources and credentials belong to target team's deployment
Organization catalog	Organization discoverers	Only teams with active deployments and run grants	One version behaves like a package installed separately per team
Public or anonymous	Anyone allowed by public admission policy	Anonymous/public-safe runtime only	No personal credentials, private graphs, enterprise service account, or privileged agent invocation by default

When Marketing shares with Sales, the product copies workflow, prompt logic, UI, abstract tool requirements, output schema, and tests. It never copies Marketing credentials, private knowledge, Slack channels, personal OAuth grants, or deployment approvals.

If the registry stores mutable “latest” configuration without immutable versions and binding snapshots, operators cannot reproduce or roll back what actually ran, and reviewers approve a moving target.

Use case ID	Entry point	Responsible services	Authoritative store	Failure evidence
D01-UC-01	Agent workspace ownership and collaborator administration	Agent Control Plane manages creator and durable owner; Grant Service manages explicit permissions; Offboarding Orchestrator revokes personal dependencies; Stewardship Service records accountable human	Agent Registry and Grant Store owned by Agent Control Plane; identity lifecycle remains in Membership Service; credential lifecycle remains in Integration Control Plane	owner_principal_inactive, personal_binding_in_production, transfer_approval_missing, or failed continuity probe, with offboarding and transfer IDs
D01-UC-02	“Publish version” release review	Version Service freezes manifest; Digest Service canonicalizes content; Test and Approval Services attach evidence; Registry rejects mutation	Immutable Version Store owned by Agent Control Plane and append-only Release Evidence Store owned by Release Service	published_version_mutation, digest_mismatch, tests_missing, or approval_stale, with exact version and evidence IDs
D01-UC-03	Team catalog install and deployment form	Deployment Service targets team/environment; Capability Resolver maps requirements; Policy Service validates bounds; Probe Runner verifies positive and cross-team negative paths	Deployment and Binding Stores owned by Agent Control Plane; referenced connector, model, knowledge, and secret records stay authoritative in their owning services	target_team_mismatch, capability_unbound, operation_too_broad, foreign_team_resource, or failed negative probe, with deployment and binding-set digest
D01-UC-04	Public-share settings, revoke control, and release rollback	Visibility Service applies public class; Admission Service enforces anonymous policy; Revocation Service disables grants; Release Controller atomically promotes or rolls back; Runtime Deployer reconciles artifact	Visibility and Grant Stores owned by Agent Control Plane; Release Ledger owned by Release Service; immutable artifact and environment state owned by Hosted Runtime	public_capability_forbidden, grant_revoked, release_health_failed, rollback_target_unapproved, or reconciliation failure, with release and runtime evidence IDs

Provider collaboration and deployed-application access remain different decisions. A project collaborator may edit source without being an end user of the generated application; an app owner may use domain data without seeing the provider workspace. If customer policy maps the two, the system creates an explicit, audited, revocable binding instead of assuming equivalence.

Rollback never mutates an old version. It creates a new release decision that points the environment to a prior approved immutable artifact and compatible binding-set snapshot. Change and redeploy follow the same pipeline as the first release: new version, new digest, current tests, current approval, atomic promotion, and observable health.

Without stable version, deployment, grant, and binding records, deleting or revoking one sharing relationship can accidentally destroy the reusable definition or leave hidden runtime access behind.

Generated-application database: Not created in this slice — this day creates provider control-plane ownership, version, grant, deployment, binding, release, and evidence records; any deployed generated application retains independent ownership of its tenants, end users, sessions, roles, and domain data.

Record or entity	Store and owner	Primary key	Foreign key or opaque reference	Tenant key	Material constraint	Lifecycle and deletion	Use case IDs
Agent	Agent Registry; Agent Control Plane	agent_id	Local creator reference; local durable owner-principal reference; local home-team reference	organization_id	Name unique under organization policy; published/production agent must have durable team or organization owner and active steward	Draft may delete; published agent retires before deletion; retained while versions, deployments, or audit evidence reference it; then tombstoned	D01-UC-01
AgentGrant	Grant Store; Grant Service	agent_grant_id	Local Agent and grantor references; opaque principal reference	organization_id	Unique (agent_id, principal_type, principal_id, permission); permissions never imply one another	Created explicitly; revoked immediately; tombstone and grantor evidence retained; expires or deletes by policy	D01-UC-01, D01-UC-03, D01-UC-04
StewardAssignment	Stewardship Store; Stewardship Service	steward_assignment_id	Local Agent and user references; opaque approval reference	organization_id	Exactly one primary active steward for a production agent; steward is accountable but not owner authority	Accepted assignment activates; transfer closes prior record; retained with approval; personal metadata later minimized	D01-UC-01
AgentVersion	Immutable Version Store; Version Service	agent_version_id	Local foreign key to Agent; creator reference; opaque test and approval references	organization_id	Unique version number and content digest per agent; manifest immutable after publication	Draft revisions replaceable; published version immutable; retained while deployment/evidence references it; later archived or tombstoned	D01-UC-02
RequiredCapability	Immutable Version Store; Version Service	(agent_version_id, capability)	Local foreign key to AgentVersion	organization_id	Abstract capability and constraints contain no concrete credential; version immutability covers requirements	Created with draft; frozen on publish; expires only with version retention	D01-UC-02, D01-UC-03
AgentDeployment	Deployment Store; Deployment Service	deployment_id	Local Agent and AgentVersion references; local target-team reference; opaque runtime-environment reference	organization_id	One active release per deployment target; target team, environment, visibility, and state explicit	Created inactive; activated by approved release; disabled before delete; retained for rollback and audit	D01-UC-03, D01-UC-04
CapabilityBinding	Binding Store; Capability Resolver	(deployment_id, capability)	Local Deployment reference; opaque connector, knowledge, model, secret, or agent resource reference	organization_id plus target_team_id	Operations and argument constraints cannot exceed version requirement or target-team policy; credentials never copied into record	Versioned as binding set; revoked independently; old digest retained for release reconstruction; secret lifecycle stays with owner	D01-UC-03
VisibilityGrant	Grant Store; Visibility Service	visibility_grant_id	Local Deployment reference; opaque principal or anonymous-class reference	organization_id	Visibility and run permission separate; anonymous class cannot bind enterprise-private capability by default	Activated explicitly; revoked stops new admission; expiry optional; tombstone retained for evidence	D01-UC-03, D01-UC-04
Release	Release Ledger; Release Service	release_id	Local Deployment and AgentVersion references; opaque binding-set digest, artifact digest, approval, and prior-release references	organization_id	State machine permits one current release; promotion and rollback atomic; target version must be approved	Release draft progresses to active/failed/rolled-back; never rewritten; retained for rollback window and audit, then archived	D01-UC-02, D01-UC-04
DeploymentEvidence	Append-only Release Evidence Store; Release Service	evidence_id	Opaque actor, agent, version, deployment, binding set, probe, runtime trace, and source artifact references	organization_id	Every allow, deny, revoke, promotion, and rollback includes environment, timestamp, expected and observed result	Appended and sealed; retained by audit policy; legal-hold aware archival and deletion	D01-UC-01, D01-UC-02, D01-UC-03, D01-UC-04

Retirement is ordered: stop new sharing, disable deployments, revoke bindings and grants, export customer-owned definitions and evidence when contracted, wait for in-flight retention rules, delete runtime secrets and artifacts at their owner, then tombstone control-plane records. Removing the catalogue card alone is not deletion.