A shared, claim-aware memory of the repo for AI agents: search past sessions, commits and code structure, look up what's known about a thing, and write findings back for other agents.
search — search this machine's memory of the repo (past agent sessions, commits, code structure); every result names its source. Takes query, optional limit (default 8), on_behalf_of, and override.
about — return everything known about one thing: a file, a person, or a topic.
remember — write a fact back so the next session in any agent knows it; set claiming: true to mark work in progress rather than just note a fact.
Claim withholding — another agent's claimed work is hidden: you learn who holds it, not the answer. Ask them, pick something else, or pass override with your reason.
Accountability — overrides are recorded in the journal against your name; on_behalf_of limits a teammate to only the folders actually shared with them.
The neutral meter for AI agent work: neither side keeps the count.
Pay AI agents only when your checks pass.
For teams that pay AI coding agents on GitHub: a program holds the pay until your checks pass.
Of 241 merged agent pull requests claiming passing tests, 9 failed a test, build, lint or type check.
Check a pull request · Check every claim yourself
flowchart TB
task["You post a task, your rules for done, and the money"]
work["An AI agent or a person does the work"]
checks["GitHub runs your checks"]
paid["The worker is paid automatically, once you merge the work"]
back["Nobody is paid. At the deadline, the money comes back to you"]
task --> work --> checks
checks -->|pass| paid
checks -->|fail| backYou set the rules first. The money moves only when the work passes them.
One comment on an issue (a task's page on GitHub) posts the task, your checks and the pay: /knos fund 20 checks: test.
An AI agent or a person sends the work as a pull request.
When the checks pass and you merge the work, a program pays the worker.
Ready to try it on your own repository? Get started in five minutes.
Related MCP server: memmd-mcp
Open the check in your browser. Paste the link to an AI agent's pull request. It tells you whether the agent's checks really passed.
No pull request at hand? On the front page, press Try a sample invoice. It checks a made-up bill from an AI agent.
There is nothing to install, no sign-up, and nothing is sent to Knos.
GitHub (where your code lives) signs a token for each run of your checks. The token proves which workflow ran, on which commit. Nobody else can make it.
A workflow is the script that runs your checks. A commit is one saved version of the code.
flowchart TB
money["The money waits on Solana, not with Knos"]
run["GitHub runs your checks and signs what ran"]
copies["You and they each keep a copy"]
bill["Both copies give the same bill"]
pay["A program checks the signature, then pays"]
money --> run
run --> copies --> bill
run --> payGitHub signs which workflow ran, on which commit. Both sides rebuild the same bill, and a program pays.
You and the other side each keep a copy of those signed runs. Each side rebuilds the bill from its own copy (the command is knos meter reconcile).
The two bills match line for line, so neither side can change the count alone.
The money waits in a program on Solana, not with Knos. That program checks GitHub's signature before it pays. Today one person can still change that program, after a public wait (who holds the keys).
Today Knos earns its fee only when work is accepted. When you get a refund, the fee goes back to you. So Knos gains when work passes, and the meter is not yet fully neutral (the plan to fix it).
Why Solana: Money is released with no custodian, and neither buyer nor supplier can change the count. One person holds every upgrade key today; a program change waits 8 days in public. A custodian is a company that holds your money for you.
It runs on test money only: test USDC on Solana's practice network, devnet.
There are no customers yet. Nobody has bought anything (what is not real yet).
One person holds every key today. Any change to the programs waits in public for 8 days first (who holds the keys).
What | Today | Read from |
This copy | Release 0.3.28, October 2026. A copy naming an older release, or another product, is out of date | CHANGELOG.md; the newest: PyPI |
Reproduced by someone else | 0 of 270 | docs/reference/CAPABILITIES.md, the rows "reproduced by someone else" |
Exercised at the public devnet program ids | 26 of 270: GitHub token verification, funding by one comment, funding from a wallet, pay on merge, refund at the deadline, pause, work orders, an order paying up to four payees, orders judged by the buyer's black-box tests, auto-accepted orders, a holdback released after its warranty, top-ups, single-use tokens, one counted evaluation, a counted batch of evaluations, the seller's own count, a payee's passkey wallet, a passkey funder, the passkey relay, the site's Buy page, an x402 order, the upgrade gate, strict JSON in the verifier, an outcome that is not code, ES256 tokens in one transaction, the presentation grace | docs/reference/CAPABILITIES.md, the rows "exercised on devnet" |
Deployed at the public devnet program ids, no transaction recorded | 3 of 270: GitLab token verification, the key guardian, holding pay for a payee with no wallet | docs/reference/CAPABILITIES.md, the rows "deployed on devnet" |
Tested here only | 237 of 270, each with the test its row names | docs/reference/CAPABILITIES.md, the rows "tested locally" |
Written, not tested | 4 of 270 | docs/reference/CAPABILITIES.md, the rows "implemented" |
Outside funders | 0 | docs/NUMBERS.md, row 1 |
Outside repositories | 0 | docs/NUMBERS.md, row 2 |
Outside payees | 1, on tasks Knos funded itself | docs/NUMBERS.md, row 3 |
Payments between unrelated accounts | 3, on tasks Knos funded itself | docs/NUMBERS.md, row 4 |
Buyer interviews held | 0 | docs/NUMBERS.md, row 5 |
Letters of intent | 0 | docs/NUMBERS.md, row 6 |
Reproductions signed by GitHub | 0 | docs/NUMBERS.md, row 7 |
Outside programs reading the verifier | 0 | docs/NUMBERS.md, row 8 |
Shadow counts published | 0 | docs/NUMBERS.md, row 9 |
Paying customers | 0 | |
Revenue | 0; test USDC is not money | |
Outside security review | none | |
Key holders | one person holds every key; an upgrade waits 8 days in public | |
Network and money | Solana devnet, test USDC; mainnet is not touched |
Start at the release page: the code, how it is built, what runs on devnet, the payments and the fees.
One task from start to end, on 9 Oct 2026 with Knos 0.3.23, in a repository Knos owns, with test USDC (one step fixed by hand): funded · wrong work refused · paid · replay paid nothing more · the record.
Every other claim is one click from docs/JUDGES.md.
Knos read 241 merged pull requests by AI agents whose description said the tests pass. In 9 of them, a test, build, lint or type-check job had failed at the last commit (3.7%; the true share is very likely between 2.0% and 6.9%; docs/backtest.json). 19 had a failed check of any kind (7.9%).
A first, automatic scan counted 16 and 30. A person then re-read each one and took out 11 of the 30: they were not merged into the main branch, or the failure or the claim did not hold (docs/index_review.json, method version 1, counted by scripts/backtest.py).
A second, larger count: in 147 of 826 repositories (17.8%), the first such pull request by an AI agent had a failed check of any kind (docs/reference/BENCH.md). A failed check is GitHub's record, not a judgment of why it failed.
Pull request, devnet, multisig and more, each in one plain line: docs/WORDS.md.
Knos is the neutral meter for AI agent work. Neither side keeps the count.
You post the task, your checks and the pay before work starts. When the checks pass and you merge, a program pays the agent.
No. It runs on devnet, Solana's practice network, with test USDC worth nothing.
Checking is free; paying adds 0.30%, at least 0.05 test USDC. A tip pays the fee out of the amount instead.
A program on Solana holds it, not Knos. Today one person can change that program, after a public wait.
Not once the checks pass and the work is merged. Before that, the buyer still chooses whether to merge.
A count of work that neither side keeps alone. A program checks GitHub's signature of which workflow ran, on which commit.
Open the check and paste an AI agent's pull request. It answers within ten seconds, with no sign-up.
uvx knos shadow invoice.csv: the same check from a terminal, on a bill of your own (it needs uv, a tool for Python).
Get started: check a pull request, fund a task, get paid, install the tools.
Pricing: what Knos costs. The check is free.
Trust: who holds the keys, what is tested, and what is not.
The story: one task in seven steps, each with its evidence.
Check every claim: each claim, one click from its proof.
Every other document: the map of the documents.
Contact: open an issue, or report a security problem privately: SECURITY.md.
Below: tables that scripts write from the code and the chain, and the licence. Nobody types them by hand.
program | address | on devnet, as |
|
| runs |
|
| runs |
|
| runs |
|
| runs |
This page names no time for an upgrade, so it stays true before and after one. To see whether a change to the
programs is waiting, done or withdrawn, run knos status, or read the site's banner or its
upgrade record (web/upgrades.json is the
copy kept here).
The first set of programs (programs) has no upgrade authority, so nobody can change it.
It stays as a record, and no new task is funded there.
Reproduced by someone else: none recorded yet. Exercised on devnet: verify_github, fund_by_comment, fund_from_wallet, pay_on_merge and more, each named in the table. Deployed on devnet: verify_gitlab, key_guardian, hold_and_bind. Everything else is tested locally, implemented or not built: the table with the evidence has one row for each capability, from docs/capabilities.json. Only runs at the public program ids count here. Each capability's row also notes, with its transaction, any earlier trial run at separate test addresses (Knos 0.3.14).
MIT licence, all of it. Built by drexthealpha. Everything Knos remembers is kept by the Sibyl memory engine.
What is known about one thing: a file, a person, a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| thing | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. 'What is known' suggests a read-only retrieval operation, which is useful, but it does not state what happens for unknown entities, whether any side effects occur, or whether special permissions/identifiers are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler, and the core semantic ('what is known about one thing') is front-loaded. It earns its place without redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema present, the description is minimally adequate: it names the input concept and implies retrieval. But it leaves the parameter format ambiguous and gives no routing guidance relative to 'search' and 'remember', which are the main completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a required property named 'thing' with no description, so schema coverage is 0%. The description partially compensates by defining the parameter as a file, person, or topic, but it does not specify the expected format, identifier type, or how to distinguish between those referent kinds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description conveys a lookup-style tool for a single referent ('What is known about one thing') and gives concrete examples ('a file, a person, a topic') that clarify the resource scope. It is distinguishable from the siblings 'search' and 'remember' by emphasizing facts about one entity rather than discovering or storing, though it does not name the siblings directly and uses the vague word 'thing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need known information about a single file, person, or topic. However, there is no explicit guidance about when to prefer 'search' for broader discovery or 'remember' for storing knowledge, and the siblings are not mentioned in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write something back, so the next session in any agent knows it too.
Set `claiming` when you are about to start work on this, rather than
just noting something. Other agents are then told you have it and knos
withholds it from them until you finish or half an hour passes. Writing
a plain fact claims nothing: a note everybody can read is the point.| Name | Required | Description | Default |
|---|---|---|---|
| fact | Yes | ||
| about | Yes | ||
| claiming | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It goes beyond the schema by disclosing that claimed facts are withheld from other agents, that the claim releases when work finishes or after half an hour, and that plain facts are readable by everyone. This is meaningful, non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: purpose first, then only the claiming nuance that materially affects how the tool behaves. It is not bloated, though the typo 'knos' is a minor polish issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The essential write-and-claim semantics are well covered, and because an output schema exists, return values need not be described. However, given the locking/timeout complexity and no annotations, a complete definition should also explain the required 'about' parameter and perhaps give an example of a fact/about pair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It thoroughly explains 'claiming' and clarifies that a 'plain fact' is a shared note, but it never defines the required 'about' parameter or the expected shape/scope of 'fact'. This partial compensation leaves one required parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence identifies a concrete action — 'Write something back' so future sessions know it — and the rest clarifies that this is a shared note versus a claimed work item, which separates storing from searching. The resource is a bit vague ('something'), but the required fact/about parameters and the write-vs-claim distinction make the core purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The overall use case is implied: persist information so a future session can read it. It gives clear advice on setting 'claiming' when starting work instead of merely recording a fact, but it never explicitly contrasts this tool with the sibling tools 'search' or 'about' or states when not to use remember.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search this machine's memory of the repo: past agent sessions, commits and code structure. Every result names where it came from.
Work another agent has claimed is withheld: you get who holds it, not
the answer. Ask them, or pick up something else. If you genuinely must
have it, call again with `override` set to your reason, which is
recorded in the journal against your name.
`on_behalf_of` names a teammate when the agent is working for one. They
see only the folders they were actually shared, and nothing else.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| override | No | ||
| on_behalf_of | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden — and it excels. It discloses the withholding behavior (you get the holder, not the answer), provenance labeling ("Every result names where it came from"), the audit side effect of override ("recorded in the journal against your name"), and the access-scoping behavior of on_behalf_of ("They see only the folders they were actually shared"). These are exactly the non-obvious behavioral traits an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three paragraphs but front-loaded with the core purpose in the first sentence. Each paragraph has a distinct job: scope, withholding/override policy, and teammate parameter. It is slightly long, but every sentence carries substantive information and none is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (covering return values), the description covers the tricky semantics well: search scope, source attribution, contention handling, override auditing, and teammate scoping. The main remaining gap is the undocumented limit parameter and the absence of any guidance about result ordering or what happens on empty results — minor given the overall richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add real meaning for override (purpose + journaling side effect) and on_behalf_of (teammate context + visibility scoping), which are the two non-obvious parameters. Query is only implied by the tool name and opening sentence, and limit — its default, purpose, or effect on result volume — is never mentioned. Partial compensation for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Search this machine's memory of the repo: past agent sessions, commits and code structure." The scope is concrete and the added note that every result names its source further clarifies behavior. However, it never explicitly distinguishes itself from siblings 'about' and 'remember', so differentiation must be inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear conditional guidance: when another agent holds claimed work, the agent should "Ask them, or pick up something else," and override is only for when the agent "genuinely must have it." It also explains when on_behalf_of applies (working for a teammate). It does not explicitly state when to prefer the sibling tools 'about' or 'remember', leaving that routing implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2aboutremembersearchScored across 3 tools
search and about both query stored knowledge, so an agent could initially confuse a broad search with an entity-focused lookup, but the descriptions make the distinction clear: search returns provenance-backed results from repo memory, while about targets one thing. remember is wholly separate as a write operation.
All tool names are lowercase single words, creating a simple and consistent style; search and remember are clear verbs, while about is more of a query noun/preposition, slightly deviating from a strict verb pattern.
Three tools is well-scoped for a focused memory/knowledge server: query broadly, query a single entity, and write back. Each tool has a distinct role and none feel redundant or missing at this level of abstraction.
The core read/write/query lifecycle for shared repo memory is covered, and claimed work handling is integrated into search and remember. Minor gaps exist around updating or forgetting explicit memories, but agents can work around these with search.
Shared memory for coding agents. Stop re-explaining your codebase every session.
One shared brain for your AI coding agents: team memory, agent Q&A, tasks, and file claims.
One memory for you and your AI agents, shared by ChatGPT, Claude, Gemini, Grok, Codex and Cursor.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
