---
title: "FAQs"
description: "Frequently asked questions about Eve."
---

## How do I view my agent's observability and drill into conversation traces?

When you deploy an Eve agent to Vercel, the platform auto-detects `eve` as the framework, which surfaces an **Agent Runs** tab under your project's **Observability** view in the Vercel dashboard. From there you can browse sessions and drill into each conversation's trace.

> The Agent Runs tab is currently gated: your Vercel team needs the feature enabled before it appears. If you don't see it, reach out to your Vercel contact to get your team enabled.

Agent Runs is separate from the OpenTelemetry exporters configured in [`instrumentation.ts`](../advanced/instrumentation). Those still work and are the recommended path if you want spans in Braintrust, Datadog, or another third-party backend.

## Does Eve use the Chat SDK?

Eve uses Chat SDK's **card-builder components** (Cards, Buttons, Actions, etc.) for composing rich Slack messages. When you build a card with Eve's Slack channel, the underlying primitives come from Chat SDK and get converted to Slack Block Kit at post time.

Eve does **not** use Chat SDK's runtime. The `Chat`, `Adapter`, and `Thread` primitives are never imported or reachable through Eve's public API. Eve's channel layer (webhook handling, signature verification, event parsing, and thread management) is implemented inside Eve itself (see [Channels](../channels/overview)).

In short:

- Building Slack messages: the components feel just like Chat SDK cards.
- Wiring a channel: you author against Eve's `defineChannel(...)` API, not a Chat SDK adapter.

## How is session data persisted?

Eve persists session state automatically using the [Workflow SDK](https://workflow-sdk.dev), an open-source TypeScript library that makes ordinary functions durable, resumable, and crash-safe. Each Eve session corresponds to one workflow run: when a new message comes in, the runtime either starts a new workflow or resumes an existing one, and the durable context is serialized and threaded forward across each model-call boundary so the session can be reloaded on the next turn.

You don't write workflow code directly. Workflow primitives (`start()`, `resumeHook()`, etc.) are an implementation detail of Eve's runtime layer; channels, tools, and hooks never touch them. This separation is enforced by the framework's mechanical invariants.

If you want session data from your own code, there are two supported surfaces:

- **Tools** can read the current session's metadata (id, turn, auth, parent lineage) via `ctx.session` from the optional `ctx` parameter on `execute`. This is read-only.
- **`defineState`** is the supported pattern for reading or writing session-scoped durable state from authored code. See [Session context](../advanced/session-context).

For the wire-level session lifecycle (creating sessions, streaming events, reconnecting by event index) see [Sessions, runs & streaming](../advanced/sessions-runs-and-streaming).

## Why didn't Eve discover my file?

Run `eve info`. It lists the discovered surface and prints discovery diagnostics. From there, check that the file sits in the right authored slot and that the root-vs-subagent boundary is valid. See [CLI](./cli) and [Project layout](./project-layout).

## Why can't I call `ctx` at the top of my module?

Runtime helpers on `ctx` (like `ctx.session`) only work inside active authored execution (tools, hooks, lifecycle callbacks), not at module top level. See [Session context](../advanced/session-context).

## Where do auth and network policy live?

On the channel that handles the inbound request. See [Auth & route protection](../advanced/auth-and-route-protection).
