sourceant

Software intelligence for you and your coding agents.

AI is writing code faster than you and your team can understand it. SourceAnt helps you stay ahead. It shows you what is being built, checks changes against your decisions and requirements, and keeps your system architecture visible as the code moves.

You can let agents move quickly without giving up control of where your software is going.

It runs on a laptop with nothing configured and no account.

How it works

SourceAnt tracks four connected views of your software:

1. Code graph: A map of your files, symbols and the relationships between them.
2. Knowledge graph: What you know, or should know, about the code. This includes decisions, rules, constraints and conventions.
3. Requirements graph: A specialized part of the knowledge graph that records what the software is supposed to do and links it to the code and tests that carry it.
4. System graph: Living architecture documentation that shows how services, components, repositories and datastores connect.

SourceAnt uses this information to review code with your intent in view. It also gives you and your agents the architecture and context needed to understand how the system fits together.

This helps you answer two questions:

1. Do I understand what is being built and where it is taking the system?
2. Are my agents still respecting the decisions and requirements that matter?

Use SourceAnt locally

Install SourceAnt to get:

• One local code index for all your repositories.
• Local knowledge and requirements that persist between sessions.
• Local code reviews before a change reaches your colleagues.
• Context over MCP for the coding tools you already use.

Catch context-blind changes early. Keep the useful knowledge they uncover. Stay in control of what ships.

Start here

SourceAnt is two binaries and a core. Take sourceant and sourceant-agent for your platform from the CLI releases and the agent releases, and put them on your PATH.

sourceant install     # pulls the core and writes down which one to start
sourceant-agent       # supervises it, keeps the index current, serves the view
sourceant ui          # opens the view in a browser

install needs Docker. The index goes in your user data directory, so a second repository joins the same store under its own scope rather than leaving an artifact in the folder.

Add a repository from the Repositories page. SourceAnt parses every file the repository does not ignore, then reads it again on the schedule you set in Settings, reparsing only what changed.

Point an MCP client at the agent and it reads your code, knowledge, requirements and system context:

http://127.0.0.1:8930/mcp

Settings has the block to paste into your client. See Local index for the whole command set, and Knowledge and context for what the server exposes.

From source

git clone https://github.com/sourceant/sourceant.git
cd sourceant
pip install -r requirements.txt

./sourceant db upgrade head
./sourceant repo add ~/code/your-project
./sourceant index ~/code/your-project --update

How the graphs behave

Code graph

Files, symbols, imports and definitions. Built by sourceant index, or loaded from a SCIP index another tool produced. A local index describes the working tree. Code used in a review is pinned to the reviewed commit, so it cannot cite uncommitted work.

Knowledge graph

What the team decided and why. Every item has a kind: decision, rule, constraint, convention. A requirement is a kind within this graph, so what the software is meant to do sits beside the reasoning behind it and answers the same searches.

Requirements form a specialized subgraph with their own links and coverage queries.

Knowledge is filed against the repository, not a commit. A decision recorded once keeps applying to every later change.

Items link to each other, and to the files they govern. That link is what lets a review of one file find the decision that constrains it.

In a local installation, this knowledge is used only by reviews run on that same local instance.

System graph

Living documentation of how your software fits together and how that architecture changes. It shows you where code is pushing the system, so you can decide whether to allow that direction. It gives your agents the connections between services, components, repositories and datastores before they change code.

The graph is independent of repository layout, so one system can span several repositories and one repository can hold several systems.

Two more stores answer the same interfaces but keep nothing in the core: contracts, the API surfaces and what changed between versions, and review findings, what a review raised and what became of it. A plugin makes either durable.

Separate lifecycles, shared context

A scope is an open map of key-value pairs you choose. A personal project can use {"project": "shop"}. An integration can use {"organization": "acme", "repository": "acme/billing"}. Nothing in the core needs to know which keys you picked.

Scope lets an application join related records without pretending they age together. Local code follows the working tree, review code follows a revision, knowledge belongs to a repository, and system records describe architecture across repository boundaries. A query names one scope, so asking across two repository scopes at once is not something the core does yet.

Over MCP

To an MCP-enabled agent this is ordinary instruction:

Remember that project shop uses signed webhook requests. Store it as an approved decision.

Connect the signed webhook decision to the rule that rejects unsigned requests.

Get the approved knowledge related to the signed webhook decision before changing its handler.

Storage is replaceable. Inject another KnowledgeRepository, TopologyRepository, or CodeIndexRepository and the same tools keep working against it.

Applications

• Code review reads the graph for structure around a change before it comments.
• Issue triage finds duplicates and labels what comes in.
• Repo management automates the housekeeping around both.

These need model access and, for GitHub, an app.

Documentation

Models come through LiteLLM, so Gemini, Anthropic, OpenAI, DeepSeek, Mistral, and 100+ other providers work by setting two variables.

SourceAnt Cloud

The core is MIT licensed and self-hostable in full. SourceAnt Cloud runs the same engine with a managed layer on top: memory your team curates, contract analysis, continuous indexing at scale, the explorable graph, workspaces and roles, and analytics.

Contributing

1. Fork the repository.
2. Create a branch: git checkout -b feature/your-feature.
3. Commit your changes.
4. Push and open a pull request.

Tests and formatting are what CI checks:

docker compose exec app pytest src/tests/ -v
docker compose exec app sourceant code lint

License

MIT. See LICENSE.

Contact

• Email: hello@sourceant.ai
• Issues: Open an issue

Maintained by WhileSmart.