Bring your own agents

Tower is the mission-control layer, not the owner of every agent runtime. An operator can register a customer-owned agent, prove that Tower can reach it, then assign a whole mission or an individual task to it. The provider continues to execute the agent; Tower supplies roster routing, policy, approvals, durable mission state, attribution, and audit evidence.

Supported execution routes

Remote plaintext HTTP and WebSocket connections are rejected. Loopback connections may use http:// or ws:// for local development.

Direct Databricks App execution, local-process spawning, and arbitrary custom WebSocket protocols are not active adapters in this release. A Harness agent hosted by a Databricks App can instead expose the HTTP task contract and enroll as a TechFabric Harness HTTP agent.

The current OpenClaw adapter supports token-authenticated gateways that allow a protocol-4 connection without device pairing. Paperclip-style persistent device keys and operator-approved pairing are the next OpenClaw onboarding slice; Tower does not auto-approve a new device with administrator scope.

Enroll and activate

1. Open Squad and choose Add agent.
2. Enter a stable agent ID, display name, and routing role.
3. Select the provider and connection type.
4. Add skills and runtime capabilities used by the Tower Lead when it routes a mission.
5. Add an opaque credential reference when the provider requires authentication.
6. Choose Register & test.

Registration invokes the governed tower.register_agent action. The connection test separately invokes tower.certify_agent, performs a bounded provider handshake, and records adapter version, safe checks, capabilities, and the check time. A successful profile shows Ready, a failed one shows Activation failed with retryable evidence, and Tower keeps both pending and failed agents out of planning and refuses direct assignments to them until the check passes.

Re-registering an agent clears its prior certification, because its connection, identity, or capabilities may have changed.

Assign missions

The Missions composer lists ready squad members. Select a specific agent when a mission must use it, or leave Auto-route across ready squad selected. The Tower Lead receives only the ready roster and routes tasks by role, skills, and capabilities. The selected agent ID is preserved as the preferred assignee.

Internal tasks execute immediately. A task classified as an external effect still parks at tower.ticket_required.v1, because bringing an agent of your own grants it no approval rights and does not move it past the human ticket gate that every other actor waits at.

Tower also binds execution attribution to the assignment, so one agent principal cannot execute a task assigned to another registered agent. That binding is what makes a run history answerable months later, when somebody asks who did a thing and on whose authority.

Expected successful task output is a Markdown deliverable attributed to the registered agent ID. Run history retains the governed invocation, mission and task IDs, duration, status, and provider-reported model or token usage when available.

Generic HTTP task contract

Tower sends an authenticated POST to the registered HTTPS endpoint with a stable Idempotency-Key header.

{
	"version": "tower.agent-task.v1",
	"idempotencyKey": "tower-task:tenant-id:task-id",
	"tenantId": "tenant-id",
	"agent": {
		"id": "research-agent",
		"name": "Research Agent",
		"role": "researcher"
	},
	"mission": { "id": "mission-id" },
	"task": {
		"id": "task-id",
		"title": "Research the account",
		"summary": "Return an evidence-backed brief."
	}
}

For the strongest activation evidence, return X-Tower-Agent-Protocol: tower.agent-task.v1 from the bounded HEAD probe. Endpoints that omit the header can still activate with a warning; Tower then validates the response shape on the first execution.

Return JSON containing a non-empty output, body, result, summary, message, or data value. Optional title, model, and usage fields are projected into the deliverable:

{
	"title": "Account brief",
	"output": "The account meets the qualification criteria.",
	"model": "provider/model",
	"usage": {
		"inputTokens": 120,
		"outputTokens": 48
	}
}

The endpoint should make the same idempotency key return the same logical result. Tower bounds the request and treats authentication failures, rate limits, empty output, timeouts, and non-success responses as explicit task failures.

Credential references

Never paste a token, password, or API key into agent metadata. Use one of:

env://HERMES_TOKEN
binding://OPENCLAW_TOKEN
databricks-secret://scope/key
secret://tenant/path

env:// and binding:// resolve at the trusted worker boundary. databricks-secret:// uses the configured Databricks workspace identity. secret:// requires a tenant secret resolver supplied by the deployment. Hermes and the current token-authenticated OpenClaw adapter require a resolvable credential reference. Resolved values are not written to registration events, activation evidence, mission records, task records, or model context.

Databricks prerequisites

Databricks routes use the Tower workspace identity through @fabric-harness/databricks. Grant only the permissions required to read or invoke the selected Job, serving endpoint, Agent Bricks resource, or Genie space. Do not place workspace tokens or resource credentials in the registration form.

Live certification requires the corresponding resource to exist and the workspace identity to be configured. Offline development remains deterministic, because the provider adapter tests use fake gateways and never reach the network.