I’ve been working on Agentique, a free and open-source project for sharing, packaging, and validating AI agent resources.
The problem I kept running into is that agent resources are often shared as loose repos, prompt files, config folders, or zip files. That works when you already trust the author, but it gets harder when you want to inspect something before reusing it.
Before running or adapting an agent resource, I usually want to know:
- What runtime does it expect?
- What tools or APIs does it call?
- What secrets or permissions does it require?
- What files are included?
- Is there a manifest?
- Can I inspect the metadata without executing the package?
That led me to build a companion repo with a few developer-facing pieces:
- Public schemas
- A validator
- Starter examples
- A GitHub Action
- Readback tooling for resource metadata
The goal is not to build a closed marketplace. I’m more interested in making agent resources easier to package, inspect, and validate in a way that others can audit or reuse.
Agentique.io is the website side of the project, where resources can be browsed and shared. The companion repo contains the tools developers can use directly.
Website: https://www.agentique.io
Repo: https://github.com/rookiestar28/Agentique
It’s still early, but the project is usable now. I’d love feedback from anyone building, publishing, or reusing AI agent templates.
What metadata would you want to see before trusting an agent resource?
Top comments (2)
A toolkit for agent resources is a useful thing to design carefully, because how an agent's tools and resources are organized has a bigger effect on reliability than people expect. The trap is the everything-bucket: expose a huge flat pile of tools and resources and you both blow context (every tool's schema taxes every call) and confuse the model (more options means more chances to pick the wrong one). So the design principles I'd center are scoping and discoverability, give the agent the minimal relevant set for the task, with clear names and contracts so it picks correctly, rather than a giant menu it has to reason over. The resource side has the same shape as retrieval: surface the few resources that matter for the current step instead of loading them all, because an agent drowning in available resources reasons worse, not better. And since it's open-source, the highest-leverage thing the toolkit can bake in is the reliability defaults everyone reimplements badly, scoped permissions per tool, validation on tool output, and bounded usage, so adopters inherit the safe patterns instead of rediscovering them in production. Curate and scope the tool/resource surface, don't just expose it. That minimal-relevant-surface instinct is core to how I think about agent tooling in Moonshift. How does the toolkit decide which resources to surface to an agent, manual configuration per agent, or some relevance/selection mechanism?
First of all, thank you for your thoughtful reply and highly valuable suggestions. This is exactly the direction I want Agentique.io to move toward.
I agree that the failure mode is the everything-bucket. A registry that simply exposes a huge flat list of tools/resources to an agent is not very useful, and can actively make the agent less reliable.
My current thinking is to treat resource surfacing as a layered problem:
Manual / manifest-defined scope first
Each agent resource should declare its intended capabilities, required tools, compatible runtimes, permissions, and resource dependencies. That gives users and downstream clients a bounded starting set instead of the whole catalog.
Policy gates before relevance
Before any relevance mechanism is allowed to surface something, the resource needs to pass basic trust and safety constraints: visibility, license, scan status, permission class, owner policy, compatibility, and whether the current task is allowed to use that type of resource.
Relevance / selection as a second layer
After policy filtering, Agentique can rank or select resources by task intent, tags, compatibility metadata, examples, prior usage patterns, and explicit user/agent preferences. I do not want selection to be purely embedding-based without permission and contract checks in front of it.
Small context bundles, not raw catalog dumps
The output should be a small task-specific bundle: resource summary, contract, permission requirements, safe usage notes, and links to fetch more detail if needed. The agent should not get every schema and every resource up front.
Validation and bounded use
I also agree on output validation and bounded usage. The toolkit should make it easy to define allowed inputs, expected outputs, rate/usage limits, and failure behavior per tool/resource.
So the short answer is: initially manual configuration and manifest-defined scope, but designed so it can evolve into policy-filtered relevance selection. I think the important part is that relevance should never bypass scope, permission, and contract boundaries.