Composable Ephemeral Harness

Compose.Work.Destroy.

A harness that gathers the context you need for your use case. Open it, do the work, and it tears itself down. The record stays.

Get started See a use case

soc-triage.harness.yaml

apiVersion: quiv.dev/v1alpha1kind: HarnessFramemetadata:  name: soc-triagespec:  runtime: pi  model:    provider: anthropic    id: claude-sonnet-4-5  ttl: 2h  repositories:    - repository: github.com/acme/detections      revision: main  mcpRequirements:    - splunk  activityLog: true  summarize: true

apiVersion: quiv.dev/v1alpha1kind: HarnessFramemetadata:  name: soc-triagespec:  runtime: pi  model:    provider: anthropic    id: claude-sonnet-4-5  ttl: 2h  repositories:    - repository: github.com/acme/detections      revision: main  mcpRequirements:    - splunk  activityLog: true  summarize: true

soc-triage

Archived

github.com/acme/detectionsmain

splunkconnected

claude-sonnet-4-5anthropic

activity logrecording

›triage the impossible-travel detection

sha256:9f2c41d8e7b0…a3sealed

active → archived → sealed

Compose from what you already run

Anthropic

OpenAI

Gemini

GitHub

Slack

Linear

Notion

Splunk

Elastic

AWS

Temporal

MCP

Anthropic

OpenAI

Gemini

GitHub

Slack

Linear

Notion

Splunk

Elastic

AWS

Temporal

MCP

Anthropic

OpenAI

Gemini

GitHub

Slack

Linear

Notion

Splunk

Elastic

AWS

Temporal

MCP

The idea

Composable. Ephemeral. Auditable.

Composable

Name the repositories, MCP servers and integrations it needs. They resolve from your catalog and sign in when it launches.

Ephemeral

It exists while the work does. Park it to keep context without compute. Archive it and nothing is left running.

Auditable

Archiving is not deletion. The composition, the activity log and the session summary all outlive the container.

Use cases

When something happens, your workspace already knows.

Gathering context is cheap, tedious and unbounded. Deciding is not. A harness does the first part before you open it and leaves the second to you.

Trigger

Splunk · detection 4471

Impossible travel · svc-payments

Two successful logins, 4,100km apart, 18 minutes.

Gathered first

Asset owner and on-call rota from the CMDB
24 hours of authentication events for the principal
Related detections on the same asset this week
The runbook for this detection ID
The last six tickets that closed as false positive

Composed of

soc-triage

mcp: splunk, crowdstrike (read-only)
tools: github
ttl: 2h

An analyst opens a workspace that has already done the legwork, and spends their time on the decision instead of the gathering.

Every alert arrives with its homework done.

Read the full case

Trigger

PagerDuty · P1

checkout-api error rate 12%

Sustained for 6 minutes. Paged at 03:14.

Gathered first

The service runbook and its escalation path
The last four deploys, with diffs and who shipped them
Error logs and traces for the affected window
Every prior incident on this service
Current dependency health

Composed of

incident-response

mcp: datadog, pagerduty
tools: github
ttl: 4h

Nobody is grepping dashboards half awake. The workspace comes up knowing what changed and what broke last time.

Nobody should start an incident from nothing.

Read the full case

Trigger

Datadog · monitor 88

checkout-api p99 +340ms

Since 4.18.2, forty hours ago. No page fired.

Gathered first

The monitor, its history, and when the current level actually began
Traces from the slow tail, grouped by what they have in common
Every deploy to this service and its dependencies inside the window
The same monitor on every other service sharing that dependency
Prior times this monitor fired, and what closed them

Composed of

latency-triage

mcp: datadog, sentry
tools: github
ttl: 2h

An engineer opens a workspace that has already tied the regression to a change. When the monitor spans several services, the same template fans out one harness per service, each with its own deadline, and a quota that bounds the whole sweep.

Nothing paged. Something still changed.

Read the full case

Composable

Plug in what you need. Nothing more.

Define it in code or in the UI. Parts resolve from your workspace catalog, authenticated to whoever launched it.

Repositories

acme/backend

acme/legacy-tooling

MCP servers

slack

google-docs

Integrations

github

Context

eng-oncall

backend-review.harness.yaml

Active

acme/backendmain

acme/legacy-toolingdefault

slackcatalog

google-docscatalog

githubgh · signed in

eng-oncall7d · 5m

piclaude-sonnet-4-5ttl 4hsmall activity log summary

sha256:9f2c41d8e7b0…a3

v1alpha1

apiVersion: quiv.dev/v1alpha1kind: HarnessFramemetadata:  name: backend-reviewspec:  runtime: pi  model:    provider: anthropic    id: claude-sonnet-4-5    credential: session-setup  ttl: 4h  size: small  repositories:    - repository: github.com/acme/backend      revision: main      destination: backend    - repository: github.com/acme/legacy-tooling      destination: legacy-tooling  mcpRequirements:    - slack    - google-docs  toolRequirements:    - github  slackChannels:    - channel: C0123ABCD      label: eng-oncall      lookback: 7d      sync: 5m  activityLog: true  summarize: true

Named, not wired.mcpRequirements: [slack] means "slack, as this workspace defines it". Not a URL, and never a credential.

Resolved at launch. The catalog supplies the endpoint; the person who pressed the button supplies the credential.

Frozen once launched. Editing a template mints a new version. Anything already running is untouched.

The workspace

In the browser, or in your own shell.

Open a harness and the agent is already running with your context loaded. One command opens the same session in your own terminal.

soc-triage · pty

Active

› serverless connect soc-triageattached · soc-triage · ttl 1h47m remaining › ls context/auth-events-24h.jsonl  detections.json  runbook-4471.mdasset-owner.json       prior-tickets.md › pi "is 4471 consistent with the VPN egress change?"Both logins authenticated from the same device ID and thesame refresh token. The second egressed via the new Frankfurtpool, added in change CHG-2209 four hours before the alert.Nine prior tickets on this detection closed the same way. Recommend: false positive. Your call.

~/acme

$ brew install quivdev/tap/serverless$ serverless login --api-url https://acme.getserverless.ai$ serverless harness list NAME         TEMPLATE         STATUS   TTLsoc-triage   security-triage  active   1h47mmon-88       latency-triage   active   3h02m $ serverless connect soc-triageattached · soc-triage · Ctrl-\ to detach

Delegated, not a service account

A credential acts as the person who created it and reaches exactly what they can reach, resolved fresh on every request. Lose access in the app and the credential loses it at the same moment.

Compose from here

List, create and destroy harnesses without opening a browser. Create one and wait for it to be ready, with --json on the read commands.

Auditable

An archived harness is not a deleted one.

Four records survive the container, and each one is honest about its limits.

How isolation works

notes/session/2026-08-14T12-34-56-789Z.md

Sealed

# Session · 2026-08-14T12:34:56Z - Started: 2026-08-14T10:02:11Z- Ended:   2026-08-14T12:34:56Z (ttl expired)- Duration: about 2 hours- Agent: pi- Launched by: dana@acme.com- Also seen acting: sam@acme.com (probably) --- ## What was done## What was decided## Left unfinished## Start here next time

The four headings are the ones the agent is asked for. The filename is an ISO instant with : and . replaced by -, so a session log sorts chronologically as plain strings with no index behind it.

The frame digest

sha256:9f2c41d8e7b0…a3

The exact composition it ran. A frame version is deduped on the SHA-256 of the document itself, so the digest is the composition. Reproduce the harness from it months later.

The activity log

retention: your workspace’s window

Prompts as they were typed, the tool calls they caused, shell commands run outside the agent, and file operations. Not the agent’s replies, not tool results, not the contents of any file.

The notes

no expiry

The shared note and each member’s own. Deliberately not gated on the harness being alive. A torn-down harness still opens its notes, which is when somebody is most likely to want them.

The workspace audit log

no write API, no delete button

Who did what to the workspace: launches, teardowns, attaches, template edits, credential revocations. Refusals too, recorded as the action that was attempted with an outcome of denied.

Written once, by nobody

A session note is immutable by construction rather than by permission. The code asks "may anyone ever change this" as a separate question from "may this person write here", so there is no grant, no role and no administrator that makes a summary editable, including one who revives the archived harness.

The summary outlives the log

Activity records are kept for the window your workspace sets, thirty days by default, and are deleted nightly after that. The summary is a document rather than a row: it stays readable once the records behind it are gone, which is why the names, and their hedges, are written into it as it is stored.

How it works

The lifecycle of a serverless harness.

Compose

Name the repositories, MCP servers, integrations and context the work needs, plus the model and how long it may live. It is a file, so review it in a pull request like anything else you ship.

Work

Start one from the dashboard, from your terminal, or let a trigger do it. Context is gathered before the agent takes its first turn, so you open the harness to a prompt already inside the work.

Destroy

Delete it, park it, or let the deadline do it. A time to live is not optional. Nothing is left running, and nothing is left to pay for.

Audit

On the way out the harness writes down what the session did. One document, created once, that no permission and no administrator can edit afterwards.

FAQ

Questions that come up first.

Start with the context already gathered.

Create an account, compose a template, and start your first harness.

Create an account Log in