Ask your agent to integrate Anectico

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
Product events	Yes	Plan and prove product events
Errors	Not yet	Capture errors and releases
Traces and logs	Not yet	OpenTelemetry
Session replay	Not yet	Record session replay safely
Surveys	Not yet	Surveys
Product experiments	Not yet	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.
Browser or mobile application	Not by this server workflow. Use a client delivery key with only flags:evaluate, separate from capture. See browser flags and mobile flags and 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 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. 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.
• The anectico-integrate skill: anectico skill install <agent>. See Install the Anectico skills.
• 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 and see 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:

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.

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.

For current connection capacity, automated-work allowances and spend controls, read Manage agent budgets and 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
• Plan and prove product events
• Integrate without an SDK
• Runnable integration examples
• Verify your setup
• Your agent builds on the API