A control plane for agent work.

Quick start

1. Create an account with a unique password of at least 12 characters.
2. Create an organization and your first project.
3. Choose hosted, connected, or mirror repository mode. External URLs are saved, then an administrator initializes or synchronizes the repository. External hostnames require operator approval.
4. Open Project Context and specify the objective, architecture, protected areas, and required tests.
5. Create an agent identity and grant the minimum required scopes.
6. Issue its credential, then call the context API from your own agent or terminal.
7. Create a task, assign it, and inspect the resulting audit events.

Repository connections

A project has an independent repository connection. Changing the Git provider does not replace project context or agent identities.

Supported connection metadata includes GitHub, GitLab, Bitbucket, Codeberg, Forgejo, Gitea, generic HTTPS, and generic SSH. Credentials embedded in repository URLs are rejected.

Project context

Context is versioned canonical knowledge. It includes the current objective, architecture, important files, conventions, protected areas, required tests, active work, recent changes, known failures, and deployment expectations.

curl -H "Authorization: Bearer $BRANCHSLATE_TOKEN" \
  "$BRANCHSLATE_URL/v1/projects/$PROJECT_ID/context"

The response includes a revision number and ETag. Context writes require a human administrator and the current revision, preventing stale updates from overwriting newer instructions.

Agent identities and credentials

Agents are system principals, distinct from human users. Each identity is organization-owned, explicitly attached to projects, and assigned action scopes.

Credential values are displayed once, hashed at rest, expiring, and revocable. Rotation invalidates the previous credential. Every authenticated request resolves the current scope and project membership.

repo:read · task:claim · task:update · run:create · artifact:read

Revocation blocks future API access. BranchSlate cannot stop a remote process running in your infrastructure.

Task delegation

Tasks carry an objective, verifiable acceptance criteria, relevant files, protected areas, required tests, and a target platform. Assignees have an explicit actor type.

curl -X POST -H "Authorization: Bearer $BRANCHSLATE_TOKEN" \
  -H "Content-Type: application/json" -d '{}' \
  "$BRANCHSLATE_URL/v1/tasks/$TASK_ID/claim"

Claims are atomic. An agent can update only its own assigned tasks. Tasks with a human completion gate require an organization owner or admin to mark them done.

Human approvals

An owner or admin can approve a change or request revisions with a reason. The actor, permission, time, and reason are recorded atomically. In V0 an approval records a decision; it does not perform a Git merge or deployment.

Bring your own runner

Run requests persist as queued metadata. BranchSlate does not execute untrusted code in this milestone. The launch integration will register customer runners, authenticate callbacks, ingest logs and artifacts, and preserve task and change provenance.

POST /v1/runs
{ "project_id": "core-platform", "name": "Unit tests" }

Versioned API

The human console is a client of the same versioned services used by agents. V0 exposes /v1 and /api/v1 on the application origin; the future production API origin is https://api.branchslate.com.

Errors use { "error": { "code", "message", "request_id" } }. List responses are ordered and bounded. Unknown permissions are rejected by validation.

Data portability

Project settings include JSON export for metadata, context, task configuration, agents without credentials, changes, run records, and the full audit history. Repository snapshot exports are included for demo projects. Live Git archive export arrives with transport integration.