Now running on kagent + Vertex AI

Long-running agents that leave a trail.

Most platforms hand you an answer. Spooky Labs hands you the work: every tool call, every file touched, every subagent delegated to — recorded as it happened and replayable afterwards.

Start building Sign in

Runs on your Kubernetes. Bring your own Vertex AI project.

release-bot

run/8f2a · tenant-9f2a

Completed

Submitted task accepted

Working pod scheduled on node-7

Reading the workspace to find where retries are configured

Read /workspace/internal/runner/runner.go fs.read 42ms

Model gemini-2.5-pro 19.6k tok 3.24s

Write /workspace/internal/runner/runner.go fs.write +12 −3 88ms

Run go test ./internal/runner/... shell.exec 8.41s

Delegating the changelog entry to the docs subagent

Write /workspace/CHANGELOG.md fs.write +4 −0 31ms

Call cap retry backoff at 30s git.commit 210ms

Agent Backoff is capped at 30s with full jitter. The runner suite passes.

Completed artifacts written to /artifacts

tokens

tool calls 5

elapsed 14.8s

A2A task states, all handled

including rejected and auth-required

levels of subagent nesting

read from the real span tree

commits per mutating tool call

pre and post, so every change has a diff

The run

Open the run, not the transcript

This is the platform's run view, built from the same components the dashboard uses — an OpenTelemetry span tree on the left, the workspace commit and the artifact the agent wrote on the right.

task/38f1c2 release-bot

Submitted Working Completed

Trace · invoke_agent

invoke_agent release-bot 14.8s 29.6k

generate_content 3.24s 19.6k

execute_tool fs.read 42ms

execute_tool fs.write 88ms

execute_tool shell.exec 8.41s

invoke_agent docs-writer docs-writer 2.30s 4.1k

generate_content 910ms 4.1k

execute_tool fs.write 31ms

execute_tool git.add 18ms

execute_tool git.commit +1 210ms

Nesting caps at three; the last call is depth 4 in the data and says so.

Workspace commit a91f3ce

46 46 func (r *Runner) backoff(attempt int) time.Duration {

47 return time.Second * time.Duration(attempt*attempt)

47 d := time.Second * time.Duration(attempt*attempt)

48 if d > maxBackoff {

49 d = maxBackoff

50 }

51 return d + jitter(d)

48 52 }

Artifact

artifacts/run.json json Ready

1{2  "task": "task/38f1c2",3  "agent": "release-bot",4  "state": "completed",5  "usage": {6    "promptTokenCount": 26234,7    "candidatesTokenCount": 3376,8    "totalTokenCount": 296109  },10  "workspace": {11    "commit": "a91f3ce",12    "signature": "verified"13  }14}

Live markup, not an image — the spans, the diff and the artifact above are the production components rendering real telemetry shapes.

Observability

Every token has a name on it

Usage comes from kagent_usage_metadata on the spans themselves, so a bill is always traceable back to the invocation, the model and the subagent that spent it.

Tokens · 14d

31.3M

+18%

Across three models in one tenant

Runs · 14d

3,827

+6%

p95 run latency

14.80s

-13%

Wall time from submitted to a terminal state

Last 14 days

Tokens by model

Stacked — the three models are parts of one tenant total, so the stack answers the question the chart is asked.

Platform

Built for agents that run for hours

The hard parts of a long-running agent are not the prompts. They are the stream that has to survive a dropped connection, the workspace that has to be inspectable afterwards, and the delegation tree that has to be real.

Agents that stay up

A long-running deployment, not a job per turn. The workspace, the memory and the place in the conversation all survive across hours and days.

Streams that survive the network

Close the laptop mid-run and reopen it. The stream backfills the gap from persisted events, then re-attaches live — no duplicates, no holes.

Scrub through the work

Every mutating tool call commits the workspace. Drag the timeline and read the exact files the agent had open at the moment it decided something.

Delegation you can see

Subagents render as a real graph, built from the trace tree rather than guessed from logs. Follow one decision down three levels.

Declared, not clicked

Your agents are Kubernetes resources. Export the lot to YAML, review it in a pull request, import it into another tenant.

Signed provenance

The recorder holds the signing key; the agent never does. Each workspace commit carries a detached signature you can verify offline.

Declarative

An agent is a resource, not a wizard

Every agent is a Kubernetes custom resource. That means the tools you already trust — kubectl, GitOps, a pull request, an audit log — work on your agents without anyone building an export button.

$ kubectl get agents -n tenant-9f2a NAME MODEL SCHEDULE TOOLS AGE READYrelease-bot gemini-2.5-pro @daily 6 31d Truedocs-writer gemini-2.5-flash on-demand 2 31d Truetriage-bot gemini-2.5-flash */15 * * * * 4 12d True

			kubectl apply -f agents/release-bot.yaml

The same command in CI, in a pull request, or on your laptop. There is no other way to create an agent — the dashboard writes this resource too.

agents/release-bot.yaml yaml Ready

1apiVersion: spookylabs.ai/v1alpha12kind: Agent3metadata:4  name: release-bot5  namespace: tenant-9f2a6spec:7  model: gemini-2.5-pro8  schedule: "@daily"9  workspace:10    repo: github.com/acme/platform11    path: /workspace12  tools: [fs, shell, git, http]13  delegation:14    maxDepth: 315    subagents: [docs-writer]

Stop guessing what your agent did.

Point it at a repository, give it a schedule, and read the trail afterwards.

Open the dashboard Read the docs