Anyshift's `annie do` workflow turns production graph context into reviewed actions. In this Elastic workflow, it writes searchable Elasticsearch records (indexed documents) and an Elastic Case (a Kibana investigation ticket), verified with ES|QL (Elastic's query language).

One PR, Three Future Investigations

A developer opens PR #1923 in anyshift-backend. It changes shared/auth/session.py, a shared auth module. In GitHub, that is one pull request. In production, the affected surface is wider:

Production impact
one PR, three services
shared/auth/session.py
checkout
direct import

imports shared/auth/session.py

notifications
direct import

imports shared/auth/session.py

catalog
via lib-common

depends on the shared module indirectly

Elastic is where those teams will search logs, inspect traces, and open Cases (investigation tickets in Kibana, Elastic's UI) if the change causes errors later. The gap is timing: by then, the useful context is scattered across the PR, ownership history, dependency paths, deploy metadata, and identity systems.

This workflow moves that context earlier. Anyshift maps the affected services, owners, Identity hints, and evidence, then writes it into Elastic after review:

  • Elasticsearch records (documents teams can query later) for each affected service;
  • one Kibana Case with the PR, owners, Identity hints, tags, and evidence.
Schema showing Anyshift mapping a shared auth PR to affected services, owners, and identity routing before Elastic receives the context.

Elastic stays the investigation surface. Anyshift makes sure the important facts are already there when a human, or an Elastic agent, starts debugging.

The Facts Elastic Does Not Get From a PR

Elastic brings search, Cases, and the API surface teams already trust. Anyshift brings the upstream facts a PR does not carry into Elastic by itself:

  • checkout-service, owned by Payments, imports the changed function directly.
  • notification-worker, owned by Notifications, imports it directly too.
  • inventory-sync, owned by Catalog, depends on it through lib-common@2.4.1.
  • sandbox and deprecated consumers are skipped.
  • Identity adds routing hints across GitHub, Slack, AWS IAM, and Elastic when there is a confident match.

That context matters for humans, and for Elastic's newer Agent Builder (the Elastic surface for building AI agents). The future investigation should not start with "what changed?" It should start with the affected services, owners, and evidence already attached.

From Review to Elastic

The engineer starts with one request and reviews the plan before any write:

annie do --print "write Elastic change context and create a Case for PR #1923"
1. Check Elastic API auth
2. Write Elastic context payloads
3. Index Anyshift context in Elasticsearch (store it as searchable records)
4. Prepare Elastic Observability Case payload (the JSON sent to Kibana)
5. Verify Elastic context with ES|QL

After approval, the write path uses Elastic's own APIs. Elasticsearch stores one record per affected service. Kibana's Create Case API creates the Case with the same evidence.

Handoff diagram showing Anyshift generating an investigation JSON and runbook, then Elastic API calls writing Elasticsearch context documents and a Kibana Case payload.

The runbook starts with the impact, not the payload details:

# Generated by annie do
# Elastic change context: PR #1923 shared auth change
# Investigation: shared/auth/session.py is consumed by three production services before the alert
# Context written to Elastic:
#   - checkout-service -> checkout-service (payments)
#       evidence: checkout/auth.py imports validate_session from shared.auth.session
#       identity: github=alice-p slack=U07R3K2 aws=arn:aws:iam::123:user/alice.payments status=routing-hint
#   - notification-worker -> notification-worker (notifications)
#   - inventory-sync -> inventory-sync (catalog)

It Lands in Elastic

The Case is a real Elastic object created by the approved run:

Elastic Observability Case screenshot highlighting the Case title, creation timestamp, and evidence written by the Anyshift workflow.

Inside the same Case, Identity hints, affected services, tags, and change category are already attached:

Elastic Observability Case screenshot highlighting Identity hints, affected services, tags, and the change-risk category created by the Anyshift workflow.

The same run writes searchable Elasticsearch records. ES|QL returns the rows Elastic can use later:

service_name         owner_team       impact_type            elastic_target       identity.status
checkout-service     payments         direct import          checkout-service     routing-hint
inventory-sync       catalog          indirect dependency    inventory-sync       partial
notification-worker  notifications    direct import          notification-worker  partial

A deploy script can write "PR #1923 merged." This workflow writes why the PR matters and who should care.

Next Workflows

The next Elastic workflows are close to this one.

Pre-alert Cases. Before a risky merge, Anyshift can open a Case that says: this PR touches shared auth, these three services may feel it, Payments is the clearest owner, and this is the evidence. If checkout starts throwing errors later, the investigation is already waiting in Kibana instead of being rebuilt during the incident.

ES|QL impact search. Because the context is indexed in Elasticsearch, teams can query every service touched by a PR, module, deploy, or owner.

Agent-ready context. Elastic already exposes an Agent Builder MCP server. The same records can answer: "checkout errors spiked, what changed upstream?"

If your team uses Elastic and wants production-change context inside investigations before alerts fire, contact us.