# Ask your agent to integrate Anectico

> Have your own agent add feature flags and product events to your application, run it, and prove from Anectico's side that the exact samples arrived, with today's coverage stated.

Canonical page: https://anectico.com/docs/start/ask-your-agent-to-integrate/


You ask your own agent to add Anectico to an application. The agent reads your repository on your
machine, shows you a plan, writes the code, runs the application as a few synthetic people, and then
asks Anectico whether the exact events and flag decisions of that run arrived. Anectico supplies the
documentation, the previewed operations and the evidence reads. It does not read your repository,
write your code, run your application, host anything for you or drive the task, and it runs no model
on your behalf.

## What is covered today

Seven jobs can belong to an integration. Two are covered by this workflow so far.

| Job | Covered | Where to look for the rest |
| --- | --- | --- |
| Feature flags | Yes, on a server | [Feature flags in your application](/docs/instrument/feature-flags) |
| Product events | Yes | [Plan and prove product events](/docs/instrument/product-analytics) |
| Errors | Not yet | [Capture errors and releases](/docs/instrument/errors) |
| Traces and logs | Not yet | [OpenTelemetry](/docs/instrument/opentelemetry) |
| Session replay | Not yet | [Record session replay safely](/docs/instrument/session-replay) |
| Surveys | Not yet | [Surveys](/docs/investigate/surveys) |
| Product experiments | Not yet | [Product experiments](/docs/investigate/product-experiments) |

"Not yet" means the guides above still work, but your agent has no taught path for the job and no
exact check of its samples. The one-verdict check refuses those jobs by name.

| Application | Covered |
| --- | --- |
| Node.js server in JavaScript or TypeScript, with the Anectico JavaScript SDK | Yes. The runnable example ran on Node 22.22.0 and 24.21.0. |
| A server in any language, over HTTP with no SDK | One tested recipe. The example is Ruby 2.6.10 with only its standard library; other languages follow the same calls but were not run. See [Integrate without an SDK](/docs/instrument/without-an-sdk). |
| Browser or mobile application | Not by this server workflow. Use a client delivery key with only `flags:evaluate`, separate from capture. See [browser flags](/docs/instrument/javascript#feature-flags-in-the-browser) and [mobile flags and surveys](/docs/instrument/mobile#remote-flags-and-headless-surveys). Never embed the server definition-read key. |
| Go, Python, iOS, Android, React Native, Flutter | Not by this workflow. Their SDK guides still apply. |

No independent agent has yet integrated an uninstrumented application from scratch while a second
check watched, so none of this is a qualified result. [What has been run, and what has
not](/docs/reference/integration-verification-limits#what-has-been-run) lists the evidence.

## What you need

- The repository on your machine and a way to run the application in development, with synthetic
  people and no real customer data, payment or message.
- Your agent connected to Anectico. See [Connect an AI agent with MCP](/docs/agents/connect-mcp). A
  person runs `anectico agent bootstrap` in their own terminal. The agent never runs it to widen its
  own authority.
- A management API key for the agent. A read-only OAuth connection can inspect an integrated
  application and run the verification reads, but it cannot create a flag or a key. The exact scope
  of each step is in [Scope recipes](/docs/agents/scope-recipes).
- The `anectico-integrate` skill: `anectico skill install <agent>`. See [Install the Anectico
  skills](/docs/agents/skills#anectico-integrate).
- An SDK artifact if you want the SDK path. The public packages are not published during early
  access, so use the artifact or exact install coordinate supplied to you. With none, use the HTTP
  path. An agent must never install a guessed package name.

## Ask your agent

> Add Anectico feature flags and product events to my checkout service. Show me the plan before you
> change anything, use a synthetic test population, run the service, and tell me exactly what
> Anectico received and what it did not.

| Job | MCP tool or action | CLI command |
| --- | --- | --- |
| Check the connection and the authority the key holds | none | `anectico whoami`, `anectico doctor`, `anectico mcp verify` |
| Search and read these guides | `search_docs`, `get_doc` | none |
| Pick the project | `list_projects`, `get_project` | `anectico projects list`, `anectico projects get` |
| Reuse or create the flag | `list_flags`, `get_flag`, `create_flag` | `anectico flags list`, `anectico flags get`, `anectico flags create` |
| Learn what Anectico decides for a known person | `decide_feature_flags` | `anectico flags decide` |
| Read or prepare the application's keys | `list_api_keys`, `get_api_key`, `create_intake_key`, `create_api_key`, `revoke_api_key` | `anectico apikey list`, `anectico apikey get`, `anectico apikey create`, `anectico apikey revoke` |
| Read the pinned tracking-plan revision | `get_tracking_plan` | `anectico analytics tracking-plans get` |
| Verify the samples | `verify_integration`, `verify_integration_events`, `verify_flag_integration` | `anectico doctor integration`, `anectico doctor events`, `anectico doctor flags` |

Every write is a preview first: the agent shows you the complete proposed change, you approve it,
and only then does it repeat the identical arguments with the confirmation token. The verification
reads change nothing.

## What your agent does

1. **Connects and checks its authority.** It reads what its key holds and names every scope a step
   needs before taking the step. A step whose scope is missing is not taken, and the agent says so.
2. **Picks one project** and uses it for the key, the flag, the code and every check. It creates a
   project only when you ask.
3. **Inspects the repository locally.** It finds the runtime, where requests are authenticated and
   the person and account are known, where the business events and each flag branch really happen,
   and any consent gate. Nothing from this step is sent to Anectico: no source file, command or
   secret goes into a tool call.
4. **Reads the instructions** through `search_docs` and `get_doc`, outline first, and checks
   whether a long page was truncated before relying on it.
5. **Shows you a plan and waits for your answer.** The plan names the files, the package and where it
   comes from, the flag it will reuse or create, the events with their property names, the
   credentials by purpose and where each secret will live, the synthetic people, how it will run the
   application, and what it will remove afterwards. A yes to the code is not a yes to a key; it asks
   for each separately.
6. **Provisions through previews.** It reuses an existing flag when one fits. It creates a flag or a
   key only after you approved the exact preview.
7. **Writes the integration** in your repository, following the runnable example for the path.
8. **Runs the real application** in development as at least two different synthetic people, for
   example an anonymous visit, a login, the business action, a logout and a second person, keeping
   what the application itself reports: message IDs, identities, served branches and delivery
   outcomes.
9. **Asks Anectico what it stored**, selecting only the samples whose delivery was queued, and reads
   again with the same request a few times if a check is not yet observed.
10. **Cleans up and hands back.** It removes test-only code, keeps the integration, and reports.

## Credentials: three, never interchangeable

| Credential | Held by | What it is |
| --- | --- | --- |
| Your agent's key | The agent | A management key with the scopes of the steps it takes. It is never put in the application. |
| Flags key | Your application's server | A project-bound management key with only `flags:read`. It can read every flag definition of the project, so it stays in server secret configuration, never in browser code, a mobile app, a log, a repository or a conversation. |
| Capture key | Your application's server | A `server_capture` key with only `analytics:write`. It sends events and exposures and can read nothing. |

The application also uses two addresses: one that serves flag decisions and one that serves capture.
Nothing falls back to a default address or a default key; the examples refuse to start when a
setting is missing or both keys are equal. Create keys as described in [Native intake
keys](/docs/instrument/native-intake-keys) and see [Which credential each host
holds](/docs/reference/authentication#which-credential-each-host-holds). When there is no approved
place to put a secret that avoids a transcript, the person creates the keys and sets them in the
application's environment, and the agent never sees them.

## Prove what arrived

The agent builds one request from the samples the application reported as queued, then asks for the
verdict:

```bash
anectico doctor integration --file verify-job.json -o json
```

Over MCP the same request goes to `verify_integration` through `execute_read_action`. The answer
keeps six stages apart: the configuration you approved, the application's own run, queue
acceptance, the stored evidence, the person the events resolved to, and the verdict. Only the
stored evidence, the identity and the verdict come from the verification; the earlier stages come
from receipts and from the application's own record. A verified sample means only that the selected
samples arrived as the application reported them. A `failed` verdict in the first minute with every check
`not_observed` is delay; the same request is read again a few times. How long to wait, the bounds
and the two known gaps of the event read are on [What integration verification proves and what it
does not](/docs/reference/integration-verification-limits).

## What you get back

The agent reports the repository change by file with the purpose of each change; the project, flag
and key identifiers, never a secret; what you must set in each deployed environment; the exact
samples sent and what the application reported for each; Anectico's verdict, the read cutoff, the
window actually read and requested against observed counts; every check that did not match, and every
check it could not run for lack of a scope; what it removed; and the limits that apply. The
verification has no proof page, so there is no link to open.

## Limits to keep in mind

- **One sample is not coverage.** Upstream completeness is always unknown: sampling, consent,
  client-side loss and an accepted request are not observed.
- **Test events are ordinary events.** Anectico does not yet reserve a population for them, so they
  count in the project's measurements and allocation, and are retained, exported and erased like any
  other event. Never erase a person only to tidy up, reuse an erased identity or revive a revoked
  key.
- **A hand-sent event is a pipe check.** A command-line event proves the pipeline, not that your
  application sends anything.
- **Your application stays yours.** You host it and own its code. Normal retention, rates, event
  allocation and agent budgets apply.
- **Integrating is not building an app.** This workflow puts Anectico into your product. A separate
  program that reads from Anectico, such as a bot, a page or a report, is a different job with its own
  skill, key and limits, and nothing here qualifies it. See [Your agent builds on the
  API](/docs/agents/build-on-the-api).

For current connection capacity, automated-work allowances and spend controls, read
[Manage agent budgets](/docs/manage/agent-budgets) and [Billing](/docs/manage/billing). A read-only
OAuth connection is subject to approval capacity; connecting an agent does not grant unlimited work.

## Next

- [Feature flags in your application](/docs/instrument/feature-flags)
- [Plan and prove product events](/docs/instrument/product-analytics)
- [Integrate without an SDK](/docs/instrument/without-an-sdk)
- [Runnable integration examples](/docs/instrument/integration-examples)
- [Verify your setup](/docs/start/verify-setup)
- [Your agent builds on the API](/docs/agents/build-on-the-api)