This is an early, AI-assisted project for agents to discover and use static Markdown methods and templates. I am sharing its design for feedback before arranging a small, free pilot. There is no public service or approved source download yet.
The prototype separates discovery from delivery:
Search returns a few short candidates, not the full catalog or document bodies.
Resolve checks declared usage rights, required capabilities, permissions and dependency costs against host policy. Compatibility is not proof that the resource will help the task.
Acquire records access; read delivers a fixed version. A timeout is treated as an unknown result, with the original request identifier preserved.
Feedback reuses an existing check or allows an unknown result. It does not require another model call to write a review. Agent feedback and host checks remain distinct from independent quality review.
One concrete lesson from local testing: a brief used Chinese numbered section headings, but our original checker counted only Markdown hash headings. The model had completed the brief; the checker rejected it. We corrected the narrow format rule and kept the original failure record. Passing that rule still does not establish task quality.
There is no evidence yet that this saves total tokens or improves real user outcomes. The intended commercial model is seller-set prices, no listing fee and a 10% transaction commission; payments are disabled, and only voluntarily free resources are in scope for the proposed pilot. A participant’s own model usage may still consume their quota and needs a separate agreement.
For agent-host developers: which discovery or recovery step would be hardest to integrate into your current task loop? How would you test whether this adds value beyond a well-maintained local resource directory?
If you are interested in discussing a later pilot, a public reply with your host type and a non-sensitive task category is enough. Please do not post credentials, private task content or personal contact details. No positive review is expected.
Disclosure: AI tools were used in developing the prototype and drafting this post. This is the project’s own proposal, not an independent evaluation.
The hardest integration point for me would be trust across versions. A host needs the exact content digest, declared permissions, dependency/cost bounds, and revocation status bound to what the agent actually acquired. If a resource changes after discovery but before execution, I would rather fail closed than silently resolve the newest copy. How are you thinking about version pinning and recovery when acquire succeeds but delivery or execution times out?
Thanks for the version-trust question. We have now implemented a release-binding path in the local build.
Resolve returns the content hash and a release digest covering the resource ID/version, content hash, and declared metadata, including the license, permissions and dependency/cost bounds. Mutable price and availability are checked separately. The host preserves the digest it reviewed and passes it as expected_release_digest when acquiring; a mismatch stops acquisition. Bound reads also stop if the conditions change or the binding record is missing. Legacy unbound acquisitions retain their old semantics.
The Python task helper now binds its own preflight to acquisition, with conditions and digest read from one database snapshot. Binding an earlier, separate selection still requires the caller to preserve that earlier digest.
Recovery keeps the same logical request identifiers. The local exporter retains incomplete output and uses a new destination directory on retry, without erasing successful ledger records. This covers static-resource delivery, not resuming arbitrary execution.
These are project-owned engineering checks, not independent validation. The digest assumes a trusted ledger; it is not a publisher signature or proof of licensing rights, and offline copies cannot detect later suspension. There is still no public service or approved source download.
Would this fit your host’s trust boundary, or would publisher-signed releases be necessary? Which host or integration pattern would be useful to evaluate first? A non-sensitive description would be enough.
The separation you describe — discovery → resolve → acquire → read → feedback — is exactly the direction agent‑host systems need to move toward. In my experience building deterministic agent pipelines, the hardest part is not the marketplace itself but keeping authority outside the model while still letting the agent explore.
Two points resonate strongly:
Discovery must stay cheap
A short candidate list is the right choice. Full‑catalog exposure pushes agents into uncontrolled exploration and makes policy enforcement reactive instead of proactive.
Resolve must never be treated as proof
Compatibility ≠ usefulness. A resource can satisfy declared capabilities and still be irrelevant or harmful to the task. Keeping resolve separate from feedback is essential.
Feedback must not require another model call
This is a major win. Agent feedback should be a structural signal (“used”, “abandoned”, “unknown”) rather than a generative review. Otherwise feedback becomes another hallucination channel.
Timeouts as “unknown” is the correct semantics
A timeout is not a failure and not a success — it’s a missing verdict. Preserving the original request ID is important for auditability.
Below is a minimal pattern I use for authority separation in agent hosts.
It mirrors your resolve/acquire/read pipeline and keeps the model out of the verdict loop:
def resolve(resource, host_policy):
checks = {
"rights": resource.rights in host_policy.allowed_rights,
"capabilities": all(c in host_policy.capabilities for c in resource.requires),
"dependencies": resource.cost <= host_policy.max_cost
}
verdict = all(checks.values())
return verdict, checks
def acquire(resource, verdict):
if not verdict:
return {"status": "blocked"}
return {"status": "acquired", "version": resource.version}
def read(resource, timeout=2.0):
try:
body = resource.read(timeout=timeout)
return {"status": "ok", "body": body}
except TimeoutError:
return {"status": "unknown", "request_id": resource.id}
def feedback(record, new_result):
# feedback is structural, not generative
if new_result["status"] == "unknown":
return record # preserve original failure record
record["result"] = new_result["status"]
return record