Three Connectors, One Graph: How Discovery Engine Maps Your Entire Organization

TL;DR

• Discovery Engine's Slack, CI/CD, and Cloud connectors write to a single Neo4j graph — giving agents a machine-readable map of your entire organization.
• Agents can now traverse from a Slack conversation to the owning team, their deploy pipeline, and the running infrastructure in one query.
• This is the knowledge layer of a cyborgenic organization: institutional context that stays current because the connectors never stop running.

Every experienced engineer carries a mental map of how their organization actually works — who owns what, how deployments flow, which services run where. Most AI agents have none of it. They can read code and search docs, but they are blind to the organizational topology that makes code useful.

Discovery Engine fixes that. Three connectors — Slack, CI/CD, and Cloud — now build a complete organizational topology automatically and write it to a single Neo4j graph. Your agents can answer questions like "who should I ask about the payment service?" or "what happens when this pipeline fails?" without anyone maintaining a wiki that was accurate six months ago.

Here is what shipped.

Three Connectors, One Graph

The idea is simple: an organization is made up of people who communicate, code that gets deployed, and infrastructure that runs it. Map all three, connect them in a graph, and you have a machine-readable model of your org that agents can query in real time.

Each connector handles one dimension:

• Slack — who talks to whom, and about what
• CI/CD — how code moves from repository to production
• Cloud — what's actually running, and where

All three write to the same Neo4j graph database. That's the key. It's not three separate data stores — it's one connected topology where a Slack channel links to the team that owns a service that deploys through a GitHub Actions workflow to a GCP project running Compute Engine instances.

Slack: Who Talks to Whom

The Slack connector is a read-only analyzer that scans your workspace and extracts organizational structure from how people actually communicate.

It pulls channels, users, and user groups through the Slack API with cursor-based pagination and proper rate limit handling (Retry-After headers plus exponential backoff — we've been bitten by Slack's rate limits enough times to get this right).

For each channel, it computes an engagement score based on 7-day message volume and infers the channel's purpose from its name, topic, and description keywords. A channel called #deploy-alerts with a topic mentioning "production incidents" gets tagged differently than #watercooler. Users are scanned with bot and deleted account filtering, so you get a clean picture of who's actually active.

User group discovery via usergroups.list maps the formal team structure — engineering, platform, SRE — and connects it to the informal structure revealed by channel membership and activity.

The result: a graph of your organization's communication topology. Not an org chart that someone drew six months ago, but a living map of who's talking, where, and about what.

We shipped 27 unit tests with mocked HTTP responses covering pagination, rate limiting, and the various edge cases Slack's API likes to throw at you.

CI/CD: How Code Ships

The CI/CD connector is a multi-format pipeline parser that reads your repository and extracts the full deployment topology — no credentials required, just file analysis.

It parses six pipeline formats out of the box: GitHub Actions, GitLab CI, Jenkins (Jenkinsfile), Azure Pipelines, CircleCI, and ArgoCD. It also handles Docker and docker-compose files, plus build tool configs for npm, pip, cargo, and make.

From each pipeline definition, it extracts:

• Stages — build, test, deploy, and how they connect
• Environments — staging, production, preview, and which pipelines target them
• Deploy targets — the actual infrastructure a pipeline pushes to
• Secret references — which secrets a pipeline needs (not values, just references)
• Test frameworks — what testing tools run in CI

All of this gets written to Neo4j as a graph: Repository nodes connect to Pipeline nodes, which connect to Stage, Environment, DeployTarget, and SecretRef nodes.

We tested it against our own agent-hub repository. The analyzer detected 10 distinct topologies and 9 GitHub Actions workflows, correctly mapping the full deployment flow from commit to production. If it can handle our repo — which has accumulated a fair amount of CI complexity — it can handle yours.

Cloud: What's Running

The Cloud connector rounds out the picture with infrastructure discovery across GCP, AWS, and Azure.

It inventories VMs, databases, networks, and storage buckets across all three providers, writing everything to the same Neo4j graph. Four MCP tools and six API endpoints let agents query cloud state directly. We shipped 40 tests covering multi-cloud discovery and graph integration.

The cloud connector answers the "what exists" question — what's running, what resources are allocated, how networks are connected. Combined with CI/CD (how things get deployed there) and Slack (who's responsible), you get the full picture.

The Unified Topology Graph

Here's where it gets interesting. Each connector is useful on its own, but the real value comes from the connections between them.

In Neo4j, the graph links across all three domains. A Slack channel like #payments-team connects to users who are members. Those users show up as contributors to repositories. Those repositories contain GitHub Actions workflows that deploy to staging and production environments. Those environments map to GCP projects running specific Compute Engine instances and Cloud SQL databases.

One graph. One query language. An agent can traverse from "who's talking about payment failures in Slack" to "which VM is the payment service running on" to "what pipeline last deployed it" without calling three different APIs or asking a human to connect the dots.

This is what we mean by organizational topology. Not a flat list of resources or a static org chart, but a connected map of people, processes, and infrastructure that reflects how your organization actually operates.

What Agents Can Do With This

With the topology graph in place, agents gain capabilities that were previously impossible without deep institutional knowledge:

Incident response. An agent sees an alert from a cloud VM. It queries the graph to find which service runs on that VM, which pipeline deployed it, when the last deploy happened, and which Slack channel the owning team uses. It posts a summary to the right channel with full context before a human even starts investigating.

Change impact analysis. Before a deploy, an agent can trace the pipeline's deploy targets through the cloud graph to identify dependent services, then check Slack activity to flag teams that might be affected.

Onboarding. A new engineer asks "how does the auth service work?" An agent can pull the service's cloud infrastructure, its deployment pipeline, the team channel where it's discussed, and recent conversations about it — assembling a living answer that no static doc could match.

Topology drift detection. Agents can compare the CI/CD graph (what's supposed to be deployed) against the cloud graph (what's actually running) and flag discrepancies. That staging environment someone spun up manually six months ago? Now it's visible.

All of this happens through standard Neo4j queries and MCP tool calls. No custom integration work, no manual mapping.

What's Next

The three connectors cover the core organizational dimensions, but the graph is designed to grow. We're working on git history analysis to add code ownership signals, and calendar integration to map meeting structures to team topology. Every new data source makes the existing graph more valuable — that's the compounding advantage of writing everything to one connected store.

If you're running AI agents that need to understand more than just code — that need to know who, where, and how — this is what we're building.

Build your own cyborgenic organization at agent.ceo.