Voight Observability

DAEMON integrates Voight as an observability stream for AI agent runs, tool calls, approval decisions, terminal activity, Solana transactions, errors, and per-session traces.

What the integration adds#

Voight gives DAEMON a live event stream for autonomous workflows and production LLM activity. Events land in the Voight dashboard as a timeline that can be grouped by agent, session, trace, model, tool, outcome, transaction, and privacy level.

Setup in DAEMON#

Generate a Voight API key in the Voight dashboard, then save it in DAEMON's integration settings. Voight keys use the vk_prefix and are shown once when created, so keep the original secret in a password manager.

• Open Settings -> Integrations -> Voight Observability.
• Paste the Voight key and save it as VOIGHT_KEY.
• Pick a privacy level. DAEMON defaults to standard.
• Send a test event and confirm it appears in the Voight dashboard.
• Run an agent, tool call, patch proposal, terminal command, or Solana transaction to stream real events.

POST https://api.voight.xyz/v1/events
Authorization: Bearer $VOIGHT_KEY
Content-Type: application/json

Install path#

Voight documents four install paths: coding-agent setup, library mode for autonomous agents, production app SDK wrappers, and raw HTTP. DAEMON uses the raw HTTP path because the Electron main process can hold secrets, scrub payloads, queue retries, and post events without putting an API key in browser code.

Event schema#

Voight accepts one event per HTTP request. Unknown top-level keys are rejected by the API, so DAEMON keeps the payload inside the documented fields and puts DAEMON-specific details under metadata.

{
  "agentId": "daemon",
  "timestamp": "2026-05-26T18:00:00.000Z",
  "type": "reasoning",
  "input": { "prompt": "...", "context": {} },
  "reasoning": "optional trace text",
  "toolsConsidered": ["terminal", "filesystem"],
  "toolExecuted": "terminal.run",
  "transaction": "optional Solana signature",
  "amount": { "token": "SOL", "value": 0.1 },
  "outcome": "success",
  "durationMs": 184,
  "errorMessage": "optional failure text",
  "model": "gpt-5",
  "metadata": {
    "source": "daemon",
    "framework": "daemon-electron",
    "sessionId": "uuid-per-agent-run",
    "traceId": "optional-request-trace",
    "privacyLevel": "standard",
    "detail": {}
  }
}

DAEMON event mapping#

Privacy model#

Voight has three capture levels. DAEMON stores the selected level locally and stamps metadata.privacyLevel on each event so the Voight dashboard can show the matching audit chip.

Standard-mode scrubbing#

In standard mode, DAEMON follows Voight's documented sender-side model: every string field is scrubbed before an HTTP request leaves the machine. Voight's documented patterns include private-key blocks, JWTs, major AI provider keys, Stripe live keys, GitHub tokens, AWS keys, Slack tokens, Voight keys, email addresses, E.164 phone numbers, and Luhn-valid card numbers.

vk_...                 -> [REDACTED-API-KEY]
sk-proj-...            -> [REDACTED-API-KEY]
github_pat_...         -> [REDACTED-API-KEY]
-----BEGIN PRIVATE KEY -> [REDACTED-PRIVATE-KEY]
name@example.com       -> [REDACTED-EMAIL]

Queueing and retries#

DAEMON queues scrubbed event payloads locally and sends them asynchronously. Failed posts do not interrupt the agent run. For transient failures, DAEMON retries with backoff. For Voight rate limits, DAEMON honors the Retry-After header before sending again.

• Successful ingestion returns 202 Accepted with an event id and resolved agent id.
• 400 responses mean the payload failed validation and should not be retried unchanged.
• 401 responses mean the key is missing, invalid, or revoked.
• 410 means the target agent was deleted in Voight and ingestion is blocked.
• 429 responses must respect Retry-After.
• 500-class responses are retryable with exponential backoff.

Agent identity and sessions#

Each event includes an agentId. Voight resolves that value to an internal agent id and returns the resolved id in the accepted response. DAEMON also attaches a metadata.sessionId for each agent run so separate runs can be reviewed independently.

• Always set metadata.source to daemon.
• Use metadata.sessionId to group one agent run.
• Use metadata.traceId to group one user request or workflow.
• Use metadata.tags for per-user, per-project, or per-feature attribution when needed.

Safety model#

• The Voight API key is stored through DAEMON secure key storage, not plaintext project files.
• Renderer code never receives the key.
• Events are scrubbed before they are queued or sent.
• Terminal output is throttled and only emitted when privacy settings allow it.
• Custom integrations should put DAEMON-specific fields under metadata instead of adding unknown top-level keys.
• Payment headers, private keys, x402 payloads, wallet secrets, and raw auth headers should never be sent as event content.

Voight references#

• Voight introduction
• Quickstart
• HTTP API
• POST /v1/events reference
• Privacy overview
• PII patterns