---
title: 1. Start in OBSERVE
description: Learn what your agent actually does before you decide what it should be allowed to do.
label: Start in OBSERVE
---

New environments start in `OBSERVE` so that adding Veefore to a running system
cannot break it on day one. Everything executes exactly as before, and Veefore
records what enforcement *would* have decided.

:::danger OBSERVE protects nothing
Actions execute. An action that `ENFORCE` would block runs in `OBSERVE` and
reaches your downstream system. This mode is instrumentation. Do not leave
production in it.
:::

## What to do first

:::steps

:::step Wire the agent up and let it run normally

Protect your agent, register the tools it calls, and then just let it do its
job for a few days. Do not write policy yet. You are collecting evidence about
what the agent actually does, which is reliably different from what you think it
does.

```bash
veefore dev
```

streams every decision live with the policy and rule behind it.
:::

:::step Look at the tool inventory

```bash
veefore status
```

The first useful surprise is usually here: a tool nobody remembered the agent
could reach, or a destination nobody expected. Open the Agents page in the
console and read the agent's tool list and its recent actions.
:::

:::step Find the divergences

A divergence is a decision where the effective outcome and the shadow outcome
disagree:

```json
{
  "mode": "OBSERVE",
  "decision": "ALLOW",
  "outcome": "OBSERVED",
  "shadow": { "decision": "BLOCK", "reason": "…" }
}
```

```bash
veefore logs --limit 200
```

Every divergence is one of three things, and sorting them is the actual work of
this phase:

| | What it means | What to do |
| --- | --- | --- |
| **Correct refusal** | The agent is doing something it should not | Fix the agent, or keep the rule |
| **Over-broad rule** | The rule is right in spirit, wrong in scope | Narrow the rule |
| **Legitimate pattern you did not anticipate** | The agent is fine; your model of it was wrong | Change the policy |

:::

:::step Watch the risk signals

Open the Risk Center. In the first days a new agent trips every "new" signal —
`NEW_TOOL`, `NEW_RESOURCE`, `UNUSUAL_DESTINATION` — because it has no baseline
yet. That is correct and it will settle.

What matters is what is *still* firing after a week. A signal that fires on
nearly every action is not discriminating and its weight needs lowering. A
signal that never fires is either weighted too low or genuinely irrelevant to
your traffic. Both are tuning information you cannot get any other way.
:::

:::step Record what you learn as test cases

Every divergence you decide is a correct refusal becomes a Given/Then case on
the policy. Every legitimate pattern becomes a case asserting it is allowed.

By the time you leave `OBSERVE` you want a test suite built from real traffic
rather than imagination. That suite is what will stop a future policy edit from
breaking something you already reasoned about.
:::

:::

## How long

Long enough to see your traffic's variety. Concretely, long enough to have seen:

- A normal working day and a quiet weekend
- Your month-end or batch pattern, if you have one
- At least one failure the agent recovered from
- Every tool it is authorized for, actually used

For most teams that is one to two weeks. The honest signal is not elapsed time —
it is divergences going quiet. When new divergences stop appearing and the ones
you have are all deliberate, you are ready.

## What not to do

**Do not write a comprehensive policy before you have data.** You will write
rules for things that never happen and miss the ones that do. Start from a
template, then let the traffic tell you what to add.

**Do not treat OBSERVE as a staging gate.** It does not refuse anything, so
"it worked in OBSERVE" tells you nothing about whether it works under
enforcement. `SIMULATE` is the mode for that.

**Do not leave it running indefinitely.** An environment in `OBSERVE` for a
month is an environment nobody is going to promote. `veefore doctor` and the
Security Center both flag a production environment sitting in `OBSERVE`,
because that is a finding and not a configuration.

## Next

:::cards

:::card 2. Simulate | /journey/simulate
Run the full pipeline with real refusals and no side effects.
:::

:::card Write your first policy | /build/first-policy
Build the rules your OBSERVE data told you you need.
:::

:::