Project Intelligence Agent
One person maintains a network of software projects. Could a system running entirely on their own machine hold the map — and safely do some of the engineering?
A private, local-first system that discovers and indexes multiple software projects, answers questions about them with citations into real files, works out which tests a change actually needs, and attempts small, bounded repairs in isolated copies — with every safeguard biased towards refusing rather than guessing.
Operational · Private local system. It runs today, on the founder's own hardware, doing real work across the ITISYOU repositories — and it is deliberately not released: there is no public address, no way for anyone else to reach it, and no plan to expose the running system. What is public is this account of it.
- Local-first
- Not a product
Last verified
The question it answers
Can an engineering assistant be useful across many real projects while running entirely locally — no source code, no documents and no questions ever leaving the machine?
The ITISYOU network is a handful of real repositories maintained by one person. Holding all of them in one head — where things are, why decisions were made, which tests matter for which change — is exactly the kind of work a machine should help with. The catch is that these are private codebases, and the usual way to get machine help is to send your code to someone else’s computer.
This system is the other way round: the models, the indexes and every stored artefact live on the same machine as the code. What it knows, it learned locally; what it answers, it cites; and what it cannot support with evidence, it declines to say.
The loop
- Attach a project — any local folder or repository
- Discover what it is: layout, languages, commands, documents
- Index it symbol-aware, so a function is a unit rather than a random slice of text
- Answer questions with citations into real files and lines
- Watch for change, and select only the tests the change needs
- Attempt a bounded repair in an isolated copy — never in the working tree
When it is allowed to change things
The part that needed the most safeguards: an assistant that can edit code has to be harder to trust, not easier.
A repair never happens in the working tree. The system takes an isolated copy, makes the smallest change it can defend, and then has to convince the tests — the one that failed, the ones around it, and a safety floor — before anything is promoted.
Proposals are screened before they run. Paths that do not exist, edits outside the copy, changes that weaken or skip a test, and anything shaped like a destructive command are rejected outright.
When bounded attempts fail, it stops, restores the recorded state and says so. An unresolved report is a valid outcome; a lucky green is not.
- A change or failure is noticed in an attached project
- The affected area is mapped against the index
- The relevant tests are selected and run, with evidence collected
- A minimal repair is proposed and applied in an isolated worktree
- The failing tests, the affected suite and a safety floor are re-run
- Only a verified fix is promoted; anything else is rolled back and reported
Refusal is a feature
When the evidence behind an answer is weak, the system says it does not have enough evidence rather than composing something plausible. When a proposed repair touches files it should not, weakens a test, or resembles a destructive command, it is rejected outright. A system with write access to real repositories earns trust by what it declines to do.
What makes the approach interesting
Architectural choices, not claims that other tools cannot do the individual pieces.
Local-first, end to end
The language model, the vector index, the keyword index and every stored artefact run and live on the founder's own machine. Nothing about an attached project — source, documents, questions or answers — is sent to any external service.
Answers carry citations
An answer points at the files and lines it rests on, in the project it came from. Projects are isolated from each other, so a question about one cannot quietly borrow evidence from another.
Tests are selected, not sprayed
A one-file change runs the tests that cover it; a risky change — configuration, dependencies, anything security-shaped — escalates to a wider safety floor. The system decides from the change itself, not from a fixed schedule.
Repairs are bounded
A repair happens in an isolated copy of the repository, never in the working tree. Proposals that touch unrelated files, weaken or skip tests, or contain destructive commands are rejected before anything runs.
Known-good baselines and rollback
Before mutation there is a recorded baseline; after failure there is a verified way back. A rollback that belongs to a different project or branch is refused.
Everything leaves a trace
From a question in the interface to a job, a test run and a repair attempt, actions carry a correlation trail, so what the system did — and why — can be reconstructed afterwards.
What it refuses to do
A rule for each boundary, rather than an excuse for crossing it.
- Weak evidence
- Answer is refused with an insufficient-evidence message rather than padded with plausible text.
- Secret-shaped content
- Files and patterns that look like credentials are blocked before indexing, so their values are never stored or embedded.
- Instructions found inside indexed content
- Text retrieved from a project is treated as material to cite, never as instructions to follow.
- Destructive commands
- Proposed commands that could rewrite history, force-push or delete are refused deterministically, wherever in the repository they are issued from.
- Anything outside the attached root
- Paths that escape the attached project — including through links — are rejected before a scan begins.
The working tree is not the workbench
Autonomous repairs happen in isolated copies. The founder's own checkout, including uncommitted work, is never the place an experiment runs.
Only the founder's machine
The system binds to the local machine only and refuses requests from elsewhere. There is no remote access to add later — not exposing it is a design decision, not a missing feature.
Projects stay separate
Each attached project has its own index and its own scope. A question scoped to one project is answered from that project alone.
Failure is reported, not smoothed over
When a repair cannot be verified after bounded attempts, the system marks it unresolved and restores the recorded state, rather than declaring success from partial evidence.
What building it taught me
Real problems from the build record. They are the reason the safeguards exist.
01
A small local model proposes plausible but wrong repairs
- Investigation
- Early repair attempts included invented file paths, edits outside the repository, and fixes that quietly weakened the failing test instead of the failing code.
- Resolution
- Every proposal passes a gate before anything runs: paths must exist, edits must stay inside the isolated copy, and changes that weaken, skip or delete tests are rejected as a class.
- Verification
- Adversarial cases for each rejection class are part of the automated suite, alongside the legitimate-repair path that must still succeed.
02
Relevance scores made weak evidence look strong
- Investigation
- Normalised similarity scores meant the best of a bad set of matches still looked confident, so unanswerable questions were being answered.
- Resolution
- The insufficient-evidence gate was rebuilt on absolute signals rather than relative ranking, so a weak match reads as weak no matter what it is competing with.
- Verification
- Probe questions near the threshold — answerable and deliberately unanswerable — are checked automatically for refusal on one side and answers on the other.
03
Indexing whole files broke the unit of meaning
- Investigation
- Fixed-size text slices cut functions in half, so retrieval returned fragments that were correct but useless out of context.
- Resolution
- Indexing is symbol-aware: functions, classes, routes and schema definitions form natural chunk boundaries, discovered by parsing rather than guessed by length.
- Verification
- Retrieval quality is exercised by automated evaluation questions whose expected sources are known in advance.
04
An interrupted re-index could poison answers
- Investigation
- If indexing failed halfway, a naive implementation would serve answers from a half-replaced index without saying so.
- Resolution
- A new index is staged and only promoted once complete; until then, the previous index keeps answering.
- Verification
- Interruption is simulated in tests, asserting the active index stays valid throughout.
What was actually verified
Each result carries the weight it can bear and no more. These are the project's own measurements of itself — nobody else has reproduced them.
Discovery, indexing, cited answers, test selection, bounded repair and rollback work end to end
Exercised by the system's own automated acceptance scenarios across deliberately varied fixture projects, and in daily use across the founder's real repositories.
An adversarial stress campaign found real defects, which were fixed
A deliberate stress campaign against the system's own safeguards surfaced genuine defects, including serious ones. Each was fixed and the campaign re-run to passing. The point of recording this is that the safeguards were tested by attack, not by assumption.
Refusal behaviour holds near the evidence threshold
Calibration probes on either side of the insufficient-evidence threshold are part of the automated suite.
Usefulness on projects unlike the founder's own
The fixture set is deliberately varied, but the system has only ever been pointed at one person's projects on one machine. How it behaves on a genuinely foreign codebase is untested.
Independent review of any part of the system
Nobody outside the project has audited the code, the safeguards or these results. Every claim above rests on the project's own records.
Fitness for anyone else's use
This is one person's private tool, tuned to one machine and one way of working. Nothing here claims it would be safe or useful anywhere else.
Technical detail
For developers. Nothing here is needed to understand the rest of the page, and nothing here is an address, a port or a path.
Retrieval is hybrid
Semantic search over a local vector index and keyword search over a local full-text index are combined, because a rare error code and a natural-language paraphrase are found by different means.
Chunking follows the parse tree
Source files are parsed and chunked along symbol boundaries — a function, a class, a route — so retrieved context is a unit a person would recognise.
Change awareness drives test selection
Changes are mapped through an impact graph to the tests that exercise them; categories of change that history says are risky escalate the selection to a wider safety floor.
Everything runs as jobs
Discovery, indexing, testing and repair are queued jobs with recorded state, so a reload of the interface shows what is actually happening rather than what was last painted.
The stack is ordinary and local
A local language model, a local vector store, an embedded relational database with full-text search, a small local API and a local web interface. Nothing exotic, and nothing that requires a network connection to someone else's computer.
What it is not
Stated directly, so none of it has to be inferred from silence.
- Not a product, and not on the way to being one — there is no address to visit, nothing to install and nothing to join.
- Not a general coding assistant; it is scoped to projects it has been pointed at, and refuses questions it lacks evidence for.
- Not autonomous over production — it never deploys anything, and its repairs stay in isolated copies until verified.
- Not independently audited; all results are the project's own measurements of itself.
- Not a service anyone else can use — a public support agent built on similar ideas has been considered and deliberately deferred; no such thing exists today.
And the limits, in full
- It runs on one machine, for one person, and is reachable only from that machine — this is a boundary chosen on purpose, and this page is the only public surface it has.
- The local language model is small; harder repairs exceed it, which is precisely why the safeguards assume proposals may be wrong.
- Results and evaluation are self-reported: the automated suites are the project's own, run on the same machine that runs the system.
- When its local services are unavailable, the system degrades to a labelled keyword-only mode rather than full capability.
- It has not been released, and there is no supported way to install it; the account on this page is a description of working software, not an offer of it.
What this is based on
Sources for this page
- Project Intelligence Agent — working system, inspected directlyprivate source — described, not linked
The agent's repository, engineering history and acceptance records were inspected directly on the machine it runs on. Discovery, symbol-aware indexing, cited answers, change-aware test selection, bounded repair in isolated worktrees and baseline rollback are implemented and exercised by its own automated suites. It runs only on the founder's own hardware and is reachable only from that machine.
Checked 30 August 2026
Like the Thraksha page, this rests on private records: the system’s own repository, engineering history and test results, inspected directly. There is deliberately no public build to check. Treat it as a description of working software rather than a claim you can verify, and if anything here turns out to be wrong, the corrections page explains how it gets fixed.