How Anectico connects the story

Anectico brings the evidence for one customer into one timeline. You still use familiar signals such as errors, traces, logs, metrics, events, and replay; the difference is that a stable customer identity connects them so you can move through the story without searching each tool separately.

Anectico is the platform, not the agent. You bring your own AI agent and its model. Your agent reads and measures through MCP and the CLI. Anectico has no assistant of its own and does not fix anything by itself.

The short version

1. An SDK or OpenTelemetry exporter sends telemetry to one Anectico project.
2. Your application identifies a customer with a stable distinct_id.
3. Anectico resolves that ID across errors, traces, logs, events, replay, and AI activity.
4. Your agent asks Anectico for the evidence. The timeline puts it in time order, and issues group failures by cause and impact.
5. Your agent writes the conclusion and gives you links. Each link opens a read-only proof page, so you can check the claim.

Metrics remain service-level measurements. Do not add customer IDs as metric labels. When a metric changes, use the same service, environment, and time window to find the traces, logs, Issues, and customers that explain it.

What each signal answers

Signal	Question it answers	Typical example
Error / Issue	What failed, and who was affected?	Payment exception grouped across occurrences
Trace	What happened during one request or job?	Checkout request across API and payment services
Log	What detail did the application record?	Provider response or retry decision
Metric	When and where did system behavior change?	Error rate, queue depth, or latency distribution
Event	What meaningful action did the customer take?	Checkout started or onboarding completed
Replay	What was recorded of the customer's browser or native experience?	Browser UI state or masked native structure and declared actions around a failure
AI call / agent run	How did an AI workflow behave and what did it cost?	Model call, tool use, tokens, and outcome

No single signal is expected to explain the whole incident. Start from the customer or issue, keep the time window fixed, and follow the links between them. Your agent does this for you, and its links let you follow the same path.

Your agent, the Console and proof pages

Part	Its job	You use it to
Your agent, through MCP and the CLI	Does the product work: searches, measures, investigates and sets things up	Ask questions in plain words. See Connect an AI agent with MCP.
The Console	Control and onboarding: agents and keys, people, projects, connections, privacy, safety, links, billing and the audit log	Decide who and what has access. See The Console.
Proof pages	Show one thing, read-only, from a link your agent gives you	Check a claim and share it. See Proof pages.

What the SDK does

The server SDKs configure OpenTelemetry export, add service and environment information, batch telemetry, and provide helpers for errors, identity, and diagnostic events. Framework integrations can create request spans and capture unhandled failures. Browser and mobile capabilities differ, so check Choose an integration before assuming feature parity.

Mobile applications can also use remote flags and headless surveys. Optional native structural replay has separate ownership, consent and policy controls. Check each platform's source coverage before rollout.

Your application still owns four decisions:

• call identify only after authentication, using a durable ID;
• call reset on logout in stateful clients;
• propagate trace and identity headers only to trusted application services; and
• flush or stop the SDK during graceful shutdown, especially in short-lived processes.

Anectico instrumentation should not replace your application's error handling. Capture the error, then preserve the application's normal return, throw, retry, or crash behavior.

The three scopes to check

When evidence looks missing or disconnected, confirm these before changing instrumentation:

• Project — the key, your agent and the proof link must all point to the same project.
• Environment and service — use stable names such as production and checkout-api.
• Customer identity — the same stable distinct_id must reach every trusted service involved.

API-key permissions are separate from those scopes. Ingestion, diagnostic events, replay, reads, and operational actions use different permissions so application keys can remain narrow.

A safe first rollout

Start with one customer-facing journey and prove this path: identify a test customer, create one trace and captured error, ask your agent for the customer timeline, then open the issue's proof page. Add metrics, replay, more services, and automation only after that path works.

• Connect your agent and see your first customer story
• Verify your setup
• Identify customers correctly