Closed beta. Request access
Nexarch

Architecture intelligence for teams building with AI agents

The architecture your agents check before they build.

Nexarch is a living graph of your applications, data, dependencies and decisions. Your coding agents read it before they write, update it as they ship, and follow the rules you put in it. You get the map nobody had time to draw.

/workspace/architecture/applications
Applications grouped by project with control assessment results

claude-code › nexarch_resolve_reference("payments")

✓ application:demo-project-payments

depends_on  postgres, stripe-node

owner       Platform team

→ reuse beats rebuild

Agents build faster than anyone can keep track.

Duplicated capabilities.

An agent builds a payments service in an afternoon. So does the agent two teams over. Nobody finds out until both are in production.

Undocumented integrations.

Generated code wires systems together faster than anyone writes it down. The integration map in someone's head stopped being true months ago.

Unknown ownership.

When architecture is generated rather than designed, nobody ever held the model in their head, including at the moment it was written.

Before you build

You stop building the same thing twice.

Every team already has the service someone is about to write again. The problem was never that people don't ask — it's that asking meant finding the right person, and being sure they'd remember. Nexarch answers it from what your estate actually contains, in the moment the question comes up, whether it's an engineer asking in chat or an agent asking before it writes a line.

  • An agent about to create a service checks first, and says what it found.
  • An engineer can ask the same question in plain English and get the same answer.
  • Anything nobody recognises is logged, so the next person's answer is better than yours.
Claude Code · MCP

claude-code › nexarch_resolve_reference("payments")

✓ application:demo-project-payments

nexarch_list_entities({ type: "application" })

→ 14 applications found · 3 related to payments

depends_on: postgres, stripe-node

→ reuse beats rebuild

Change, made visible

Every week, the graph shows you what your agents changed.

New applications, new data stores, new relationships, drawn as they landed. The dashboard tells you what needs attention: proposed applications awaiting activation, reference names nobody resolved, decisions past their review date.

  • Proposed applications stay out of the canonical graph until a person approves them.
  • Every fact records which repository it was seen in, which agent asserted it, and when.
  • Nothing goes stale because the agents doing the work are the ones updating it.
/workspace · What grew, last 7 days
Architecture graph showing what grew in the last seven days

Policy packs

Guardrails your agents fetch, not a wiki they ignore.

Policy packs define the standards: code, testing, documentation, security. Before an agent can write to the graph it must fetch the current policy bundle and present its hash with every change. Stale rules are refused. Audits show, per application and per rule, what passes, what is partial and what fails.

  • Install a pack, apply it to your applications, run the audit.
  • Pass, partial and fail per rule, with the evidence behind each result.
  • Required rules decide the outcome; recommended ones inform it.
/workspace/controls
Control detail with assessment results by application

Decisions

Every decision, where it came from, what it changed.

Architecture decision records live in the graph next to the systems they govern. An agent that finds an ADR in a repository registers it. A decision made in a session is recorded there and then. Superseded decisions stay, marked as such, so the trail is never rewritten.

accepted

Keep the bespoke policy-markdown renderer for now

The renderer keeps policy packs portable and reviewable while the rule format is still evolving.

ADR-014 · source: docs/architecture/ADR-014.md

asserted by claude-code · repository: demo-project/platform

Every engineer who connects makes every agent smarter.

One engineer with a graph learns what they already knew. A team sharing one stops duplicating each other's work, because each registered project becomes context for everyone else's agent.

Get started

Three commands. Then your agents keep it current.

Nexarch connects to the coding agents you already use. There is no integration project.

  1. Step 1

    Connect Nexarch

    npx nexarch@latest setup

    Your terminal

    Run once in your terminal. Signs you in if needed, configures your MCP clients, writes agent instructions into this directory and registers this agent. Its identity is captured in the next step.

  2. Step 2

    Identify your agent

    Please run 'npx nexarch@latest init-agent'

    Via your agent

    Ask your coding agent to run this once. It completes the identity handshake so Nexarch records the real provider, model and client it governs. If it offers to write instructions into the repo, it must ask you first.

  3. Step 3

    Register this project

    Please run 'npx nexarch@latest init-project'

    Via your agent

    Ask your agent to run this in the repository. It registers the project and proposes its applications for review; registration finishes when the agent runs the enrichment steps the command returns.

Read the full setup guide →

Closed beta

Closed beta. Onboarding teams now.

Tell us about your team and what you'd want Nexarch to prove. Requests are reviewed by a person, usually within two business days. Workspaces shine with several engineers, so bring colleagues.

Request beta access