Map & Document Your Enterprise

Every enterprise has a landscape nobody fully understands: dozens of repositories, a few hundred servers, schemas that grew by accretion, cron jobs that run because they always have. The documentation that would explain it was never written, or was written once and is now wrong, which is worse. Onboarding takes months, incidents take hours longer than they should, and every migration starts with the same discovery project.

Discovery is a task for agents that can read the systems directly, in parallel, and keep reading.

Read what is deployed, not what was described

A Lightspeed agent borrows a real machine, and for mapping the machine is the one the system runs on: an existing host taken over explicitly or attached through its data-plane daemon. On it the agent has a workstation’s file and process tools. It reads the configuration that is actually deployed, lists what is actually listening, reads the cron table and the scheduler definitions, follows the connection string in the properties file to the database it really points at, and reads the code the host checks out. Where a system exposes an API, the agent reaches it over hosted MCP configured once for the universe. Credentials are injected into the environment and never shown to the model.

In parallel

An estate is mapped by a fleet. A coordinator splits the landscape, by host group, by repository family, by schema domain, and spawns a sub-agent for each from a profile with the tools and the environment that slice needs. Each sub-agent explores its slice and writes its findings. The coordinator merges: which job writes the file the next job reads, which service calls which endpoint under which name, which table is written by three programs and read by thirty, which server nothing calls any more. Limits on depth, descendants and concurrency keep the fleet within what the infrastructure team agreed to.

Two sub-agents disagree about an interface? Fork the coordinator, pursue both readings from the same state, keep the one the evidence supports.

Written somewhere that outlives the machines

The map lives in a virtual file system with no operating system attached: documentation, diagrams as text, notes, and the skills the agents accumulated about this particular estate, cataloged automatically. Machines are borrowed for reading and released; the map stays. A human reads it as files, corrects it as files, and the correction is a fact the agents see on their next pass.

Stays right because the agents keep looking

Documentation rots because the author leaves. A Lightspeed session lasts months and costs nothing while it waits, so the fleet that mapped the estate stays on it. On a schedule, each resident re-reads its slice, diffs it against the map, updates the map, and posts what changed. The machine is paused by idle policy in between and wakes for the next pass. A server that stopped being called is noticed in the week it happened, not in the audit two years later.

Provenance

Everything an agent read is in its event log: which host, which file, which query, which result, under which principal. The map comes with its own evidence, which matters the first time someone asks how we know that. For the regulated version of this problem, see Map Legacy Banking Systems.

A mapping run

Two hundred repositories, sixty hosts, eight databases. A coordinator with a limit of ten concurrent sub-agents and a ten-day deadline. Each sub-agent borrows a machine from a versioned image or attaches to an existing host, reads for a few hours, writes its section, releases the machine. The coordinator merges, cross-checks every interface both sides claim, and lists the ones that do not match: those are the incidents that have not happened yet. Ten days later the enterprise has a map it did not have, with a fleet still on it to keep it true, and the idle cost of that fleet is the price of a few hundred database rows.

Rests on: sub-agents, dedicated environments, environment file and process tools, virtual file system, hosted MCP, session fork and clone, credential injection, idle power policy, long-running sessions. Fleets in depth: Build Autonomous Agent Fleets.