Shared context for nine agent workflows.

Make the useful relationships explicit.

We used Neo4j as a shared knowledge and retrieval layer. It connected a ticket to its pull request, release, discussion, and related operating signals. These relationships gave workflows a way to retrieve the surrounding context for a specific piece of work.

The graph complemented source documents and prompts. Its purpose was to make these connections explicit and reusable. Freshness depended on the observers that captured changes; review depended on the evidence available to the person checking the output.

Observers capture changes. Event-driven sources supply updates as events arrive. Scheduled sources supply periodic snapshots. Nine observer categories covered the twelve systems, with Jira and Confluence grouped together and the internal systems collected through one scheduled observer.

These cadences describe collection schedules, not guaranteed end-to-end latency. A scheduled snapshot can lag the event that triggers a workflow. In particular, hourly analytics do not establish the state of checkout at the instant an incident starts.

The curator reconciles and writes. It resolves records that refer to the same customer, supplier, or product, creates connections, and flags ambiguous matches for human review. It is the only component allowed to write to the graph. Observers submit events to it rather than writing nodes themselves.

The graph MCP server supplies context. This shared tool interface exposes queries for pull request context, account changes, and the sources behind decisions. Queries are logged with the calling workflow. That log helps trace retrieval activity; it does not prove that an answer is complete or correct.

Historical review also needs the evidence as it existed at the time. A query against a changing graph is not a substitute for a saved response or source version. Likewise, an agent proposal and a human-approved decision carry different authority, even when both relate to the same event.

Shared controls for the delivered workflows.

LiteLLM provided a common gateway for model calls from the engagement's workflows. Virtual keys separated their usage and monthly budgets. The platform team could inspect model spend, latency, and failures by workflow.

The gateway also registered the shared tools, with access controlled by key. Versioned skills described tasks such as incident summaries and release communications. Internal applications invoked agents through an A2A endpoint; staff could invoke the same agents from Slack.

Smaller models handled filtering and extraction. More capable models handled work that required broader analysis. Retrieved context and cached outputs reduced unnecessary repetition. Model changes went through the evaluation suite before adoption.

Retries, cooldowns, and provider fallbacks supported recovery from failed calls. Session affinity kept multi-turn conversations on a deployment where possible, to support prompt caching. These controls reduce avoidable disruption; shared quotas, provider failures, and cache behavior still affect the result.

The client's requirements included EU data residency and human approval for production changes. Region filtering on the gateway addressed model deployment selection. It does not, by itself, establish where provider processing, logs, or backups reside.

Access to a tool is also distinct from access to every record it can retrieve. Document permissions, changes to access, and the audience for a combined answer remain separate concerns. The controls described here cover workflow and tool access; this account does not establish an end-to-end residency or record-permission audit.

Nine uses of the same foundation.

By May, the participating teams used the shared layer for the workflows below. Their common pattern was to retrieve evidence, prepare an output, and retain human review at the decision point.

The supplier and pricing workflows put the same connected context around commercial work. A disputed record still required a person to resolve it. A pricing recommendation still required approval.

From alert to a draft a person can check.

Incident triage shows how the pieces fit together. A Sentry issue on the order service triggers context collection. The draft brings release history and operating signals into one place for the on-call engineer.

1. 01 · Observe Capture the alert

   The Sentry observer sends the issue, stack trace, and release tag to the curator.

2. 02 · Connect Build the context

   The curator creates the issue node and links its release, pull requests, tickets, and deployment event.

3. 03 · Retrieve Collect the supporting records

   The agent retrieves that chain, relevant Slack discussion, the on-call record, and the available analytics snapshot.

4. 04 · Decide Keep the operational decision with the engineer

   The agent posts a draft. The engineer checks the evidence, sets severity, and decides whether to roll back.

5. 05 · Record Retain the decision and outcome

   The curator records the human decision and its supporting context for later incidents.

PostHog context came from the hourly observer. It can describe a recent reporting window without establishing live checkout impact. The engineer still needs to verify current conditions before an operational decision. The agent did not page anyone or execute a rollback.

The useful change was earlier access to a structured starting point for investigation. Producing that draft is a different milestone from validating a cause or restoring the service.

The knowledge layer needed ongoing care.

Slack needed selection. The first observer collected too much irrelevant conversation from the allowed channels. A small-model relevance filter and a channel allowlist controlled by team leads reduced that noise. Filtering also creates the risk of missing a useful decision.

Record matching remained a maintained process. Customers, suppliers, and products carried different identifiers across systems. The curator escalated uncertain matches to a weekly review queue owned by the data engineer. Keeping that queue useful was part of operating the system.

Observed practice did not settle policy. Interviews exposed differences between written processes and actual work. Source documents remained important evidence. A frequently repeated shortcut is not, on its own, approval to bypass a control.

Direct customer replies did not proceed. The client rejected autonomous support replies during compliance review because incorrect information about allergens or delivery terms carried unacceptable consequences. The delivered workflow prepared drafts for a support colleague to review instead.

The platform team took ownership.

Two client platform engineers paired with Sinumo from the first observer onward and had commit ownership by February. At handover, the team owned the graph, observers, curator, gateway, and workflows. The work also involved the client's data engineer, operational owners, and security reviewers.

• Code and infrastructure for the shared layer and delivered workflows.
• Operating guides for observers and workflows, including their maintenance responsibilities.
• A versioned evaluation suite for workflow and routing changes.
• A written operating policy for model choice, tool authority, and human checkpoints.

The account also records two workflows added by the client after May and one observer retired. These later changes are separate from the nine workflows counted at handover. They reflect the objective of giving the platform team a system it could maintain and adapt.