Build Your Own AI Agent, or Install One?

The Insulin Marketplace is a curated catalogue of pre-built agents and skills. Installing one gives you a starting configuration you then scope and ground yourself — it is a head start on the setup, not a finished specialist.

The second team to need a deal desk agent should not start from an empty system prompt. Neither should the third, the fourth, or the new hire who joins in November.

This is the ordinary duplication problem that catalogues exist to solve, and it applies to AI agents more sharply than to most things — because the hard part of a good agent is not the idea. It is the accumulated detail: the instruction that stops it hedging, the phrasing that makes it ask before assuming, the twenty small corrections somebody made over a fortnight of real use. That work is worth distributing. Retyping it is not.

What actually installs

The catalogue distributes two kinds of component, and the distinction is more useful than it first appears.

An agent is a complete specialist — a conversational entity with its own system prompt and configuration. Installing one gives you something that already knows what it is for.

A skill is narrower and more interesting: a markdown-based instruction package containing procedures or domain knowledge, which agents load during a conversation when it is relevant. A skill does not replace a specialist; it extends one. The agent your team has spent a month tuning keeps everything that makes it good and gains a procedure it did not have.

That is the composition argument, and it is why skills tend to age better than agents. An agent is a whole configuration and gets stale as a whole. A skill is one procedure, replaceable on its own.

Installs happen at two scopes. A personal install creates a private copy in your own workspace. The organization store is shown to org administrators, and installs, imports, edits and deletes there affect everyone in the organization — which is the right level of ceremony for something everybody will depend on.

What installing does not give you

An installed agent arrives configured, not finished. It is fully yours to edit, and three things still have to be decided by you:

Integration access. The catalogue cannot know which systems your organization connects, or which ones this agent should reach. Installing does not grant anything; you allowlist what its work requires, exactly as you would for an agent you built.

Knowledge bases. This is the one that decides whether the agent is any good. A pre-built deal desk agent knows the shape of deal desk work; it does not know your approval thresholds. Until you attach your own documents, it is answering from general knowledge in a confident, domain-specific voice — which is the least useful failure mode available.

The instructions. Read them before you rely on them. A pre-built prompt encodes assumptions about how a team works, and where those assumptions differ from yours, the behaviour will differ in ways nobody predicted.

So the honest framing is that installing skips the blank page and the structural decisions. It does not skip the grounding, the scoping, or the fortnight of real use that tells you whether this belongs in your workflow at all.

When to build instead

Build when the agent’s value is in something specific to you — a process nobody else runs, a vocabulary that is yours, a judgement call encoded in instructions that only make sense given your business.

That is a smaller set than teams assume. Most first agents are variations on work every company does: reconciliation checks, CRM hygiene, drafting against a policy, answering from runbooks. Starting from a catalogue version and adjusting it is usually faster and produces a better agent, because the catalogue version has already had its obvious problems found.

The useful sequence, either way:

Look before building. Five minutes in the catalogue is cheaper than an afternoon on a system prompt.
Install personally first. A private copy costs nothing and tells you the truth.
Ground it and scope it. Attach your documents, allowlist only what it needs.
Use it on real work for a week. With real consequences if it is wrong.
Then decide about the organization. An org-level install affects everyone, and withdrawing one costs more credibility than never shipping it.

Step four is the one that gets skipped, and skipping it is how organisations end up with a catalogue of installed agents nobody uses. The permission and rollout mechanics matter, but they are downstream of the question of whether the thing earns its place.

Standardising without freezing

The reason to share a good agent is that everyone starts from the same specialist rather than each person building a slightly different one. The reason that sometimes goes wrong is that a shared agent is a shared dependency, and dependencies get stuck.

Two habits keep it healthy. Give it an owner — a shared agent whose owner has moved teams is an asset with no maintainer. And prefer skills for the parts that change: a procedure that gets revised quarterly is better as a skill somebody can replace than as three paragraphs buried in a system prompt that nobody wants to touch because everyone depends on it.

Frequently asked questions

What is the difference between an agent and a skill? An agent is a complete specialist with its own system prompt and configuration. A skill is a markdown instruction package containing procedures or domain knowledge, which agents load during a conversation.

Can I edit an agent after installing it? Yes. Installed agents and skills are fully yours to edit — the system prompt, the integrations it may reach, and the knowledge bases attached to it are all set by you afterwards.

Does installing an agent grant it access to our systems? No. Installing gives you a configuration, not permissions. You allowlist the integrations its work requires exactly as you would for an agent you built yourself.

What is the difference between a personal and organization install? A personal install creates a private copy in your own workspace. The organization store is shown to org administrators, and installs, edits and deletes there affect everyone in the organization.

When should we build an agent instead of installing one? When its value is genuinely specific to you — a process nobody else runs or judgement that only makes sense in your business. Most first agents are variations on common work.

Takeaways

The hard part of a good agent is accumulated detail, not the idea — which is exactly what is worth distributing.
Agents install whole; skills extend an agent you already tuned, and age better because they are replaceable individually.
Installing skips the blank page, never the grounding, the scoping, or a week of real use.
Build only when the value is specific to you. Most first agents are variations on common work.
Give shared agents an owner, and keep the parts that change often in skills.

The Insulin Marketplace distributes reusable agents and skills you install and make your own. Explore the AI agent marketplace, see how agents are scoped, or get a demo.