AgentLens: a rental-only agent marketplace with public trust contracts
Agentlens is a trusted agent trading platform. Here, you can quickly find the Agent that meets your needs, and you can also publish your own Agent to turn it into your digital asset. We encourage everyone to transform their areas of expertise into Agents and turn them into digital assets, allowing others to see your unique strengths.
At a glance
- What is it?
- AgentLens is a trust-first marketplace and governed runtime for task-specific AI agents, published as a sanitized public source distribution under AGPL-3.0. The interesting part is not the catalog UI; it is the rental contract, the R0-R4 execution planes and the audit reference code that let a buyer inspect boundaries before renting.
- Who is it for?
- Adopt AgentLens if you need to evaluate the rental, attestation and audit contract surface before committing to a hosted marketplace, or if you are building an agent listing that must pass runtime conformance.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem AgentLens targets: renting an agent without handing over source code
Publishing an agent today usually means one of two bad options. You open the source and lose control of it, or you expose an HTTPS endpoint and ask buyers to trust a black box. AgentLens takes a third position. The README states the boundary plainly: "AgentLens provides the brain and governed runtime; sellers provide the specialized Agent." Renting grants time-limited execution access and, per the same text, "does not transfer source code or permanent ownership."
The intended audience is two-sided. Buyers are people who need a task-specific agent and want to compare evidence and execution boundaries before spending. Sellers are domain experts who want their expertise packaged as what the project description calls a digital asset. There is a third audience the repository serves less obviously: engineers who want to read the contract surface, the schemas under docs/protocols/schemas and the audit reference code without needing production credentials.
The project description frames this as turning expertise into agents that others can find. The README frames it more narrowly, as a trust-first marketplace plus workspace. The narrower framing is the more accurate one, because the repository is a public source distribution rather than the whole platform.
What the public distribution actually contains, and what it does not
The README is unusually direct about the split. Public material covers the marketplace and decision UI, rental-only smart contracts, an audit reference implementation, Agent Contract v3 and Wire v1, provider contracts, and runtime contracts. Held back are "Hosted Brain strategies, production routing, Workers, capability-broker policy, quality scoring, billing ledgers, credentials, topology and deployment automation."
That sentence should shape how you read everything else. The repository is a specification and verification surface, not a deployable marketplace. The architecture diagram in the README is explicitly labelled as describing "public trust boundaries, not the production network topology." If you clone this expecting a running exchange with settlement, you will not find one, and the README says so before you try.
The topics list on the repository is broader than the README's own prose. Topics include zero-knowledge-proofs, intel-sgx, dcap-attestation, polygon-edge and reputation-system. The README treats TEE and ZK as optional adapters that "can strengthen a record" rather than as the default path. Trust the README over the topic tags when the two disagree in emphasis.
Agent Contract v3, Wire v1 and the R0-R4 execution planes
The mechanism visible in the material is a set of versioned contracts plus a capability ladder. Agent Contract v3 and Agent Wire v1 define tasks, streaming events, tools, checkpoints, cancellation, resume, artifacts and structured failures. Wire is the frame format between a buyer workspace and the governed runtime; the security section requires that platform and seller credentials "must never appear in Wire frames, browser bundles, traces or artifacts." That is a design constraint on the protocol, not a promise about any particular deployment.
The runtime side is a five-level table. R0 sealed_ephemeral handles isolated, short-lived file and artifact tasks and is described as the base contract. R1 brokered_egress adds governed HTTP, search and connector access under permission and budget control. R2 durable_session adds checkpoints, resume, persistent volumes and long jobs with lifecycle metering. R3 browser_computer covers read-only or interactive browser sessions, separately isolated and approved. R4 accelerated_external covers GPU, special OS and very large storage and is marked reserved, with extreme workloads "currently deferred."
The important rule is the fail-closed clause: an Agent must pass runtime conformance before listing, and "unsupported capabilities fail closed rather than silently degrading." The README also warns that a schema can describe a capability without promising that every deployment supplies it. So the table is a vocabulary for negotiation, not a service-level commitment. A listing that mentions R3 tells you the listing is allowed to request R3, not that a browser session will be available when you rent.
Getting the public tree to build: the four verification commands
Requirements are Node.js 20+, npm 10+, and Docker only for container audit exercises. The README gives one install-and-verify sequence, run from the repository root:
git clone https://github.com/ZhangJinHaHaHa/AgentLens.git cd AgentLens cd contracts && npm install && npm test cd ../sandbox && npm install && npm test cd ../frontend && npm install && npm test && npm run build
To explore the UI locally, the README gives a separate two-line path: cd frontend followed by npm run dev. The hosted platform is linked at agentlens.chat, and the repository homepage field points at a raw IP address, http://203.91.76.159/, which is worth treating as a deployment detail rather than a stable entry point.
The README is explicit that this is a partial experience: "Features that require a hosted Provider, authenticated seller account or managed runtime intentionally remain unavailable in a standalone clone." There is no release retrieved for this repository, so the build you get is whatever is on main. No configuration keys beyond the npm scripts are documented in the supplied material, and I cannot confirm what the test suites assert or how long they take.
Where the trust model breaks down
The audit section contains the sharpest caveat in the README, and it is a real limitation rather than marketing hedging. Evidence is bound to versions and content hashes. TEE or ZK adapters are optional and "their presence must be verified per record and must not be inferred from a generic listing." The next line states that historical or mock attestations are not production hardware claims.
Read that as a warning about the listing page itself. A recognized listing is not automatically a sandbox guarantee, and the README says so in the product surface section. The publish flow has two paths, code artifacts submitted for platform processing or a seller-hosted HTTPS API, and the README states that "API-only listings never inherit source-audit claims." If you are comparing two agents and one has a richer evidence panel, the panel may reflect a different submission path rather than a stronger agent.
The second limitation is scope. This is the wrong tool if you want to run an agent yourself on your own hardware with full control. The hosted Brain, routing and capability-broker policy are private, so there is no configuration surface in the public tree that would let you reproduce the governed runtime. It is also the wrong tool if you need R4 today: the README marks accelerated_external as reserved and defers extreme workloads. And because there are no releases, there is no version to pin against for a stability guarantee.
How this differs from an open agent framework you host yourself
The natural comparison is a self-hosted agent framework where you own the runtime, the model credentials and the tool wiring. In that model the trust question is answered by running the code yourself. AgentLens answers it by separating the runtime from the agent and publishing the contract between them.
That difference shows up in concrete places. A self-hosted framework has no rental concept, because there is nothing to rent. AgentLens has rental-only contracts with time-limited access, reviews, audit records, appeals and reputation primitives. A self-hosted framework has no conformance gate, because you are the only operator. AgentLens requires an Agent to pass runtime conformance before listing and fails closed on unsupported capabilities.
The trade is control for verifiability. With a self-hosted framework you can read every line that runs. With AgentLens you can read the contract, the schemas and the audit reference implementation, and you are asked to verify attestation per record rather than trust a badge. The README's own framing supports this: the public contracts exist to make "interoperability and security review possible without exposing production credentials or the platform's proprietary orchestration and settlement logic." That is a deliberate boundary, and it means the public tree can never fully answer whether a given hosted deployment behaves as specified.
Licence and maintenance cost under AGPL-3.0
The repository is AGPL-3.0, and the badge in the README confirms it. For anyone considering embedding this code in a network service, that choice matters: AGPL-3.0 carries source-availability obligations that trigger on network interaction, which is precisely the deployment shape a marketplace implies. I am not giving legal advice, and the supplied material does not discuss the project's own interpretation of the licence or any commercial exception. If you plan to run a modified AgentLens as a hosted service, that question needs a lawyer, not a README.
Maintenance cost is harder to estimate from what is here. The last push recorded is 2026-08-24, and no releases were retrieved, so there is no changelog and no tagged version. The protocol surface is versioned in the schemas (Agent Contract v3, Wire v1, Research Bundle v3, Runtime Package v1), which suggests the maintainers expect those contracts to evolve independently, and a v3 label implies at least two earlier revisions. Upgrading across a contract version would mean re-checking conformance and re-verifying evidence hashes, since audit records are bound to versions and content hashes by design.
The practical cost of tracking this project is therefore not dependency churn. It is contract churn. Every bump in Agent Contract or Wire forces a re-read of docs/protocols/schemas and a re-check of any attestation record you depend on, because the record's binding to a version is what makes it meaningful in the first place.
Editorial conclusion
Adopt AgentLens if you need to evaluate the rental, attestation and audit contract surface before committing to a hosted marketplace, or if you are building an agent listing that must pass runtime conformance. Do not adopt it as a self-contained agent runtime: the README states that hosted Brain strategies, production routing, Workers, capability-broker policy, quality scoring, billing ledgers, credentials and deployment automation stay private, and a standalone clone intentionally leaves hosted features unavailable. Verify first that the R0-R4 plane you need is actually supplied by the deployment you are targeting, that every attestation record you rely on carries a version and content hash you can check, and that your own redistribution plans are compatible with AGPL-3.0.
Community notes