What makes a good one?

Narrow scope, short instructions and a named owner. The narrowest useful job is easier to describe, easier to check and easier to keep current, and the sprawling one that tries to cover a whole department is the one that becomes unmaintainable first and gets abandoned quietest.

Why did ours stop being useful?

Almost certainly because it embeds something that changed. A price, a policy, a process or an attached document that has been superseded will keep being applied with complete confidence, and nothing about that failure announces itself, which is why a review schedule is worth more than any amount of care at setup.

How many should a team have?

Few enough that somebody can name them all. Organisations that reach dozens generally find most are unused, several are wrong and nobody can say which, and the useful discipline is a short list with owners rather than an open library nobody curates.

Is this the same as what other vendors call projects or agents?

Usually yes, in shape. Saved instructions plus attached material plus a name covers most of what is sold under all three words, so the useful comparison is what each lets you attach and who can see it, rather than which term the product happens to use.

Glossary

Custom assistant

A custom assistant is a saved setup with its own instructions and material, reused by a team, and what it really encodes is one person's way of working made available to everybody.

In plain terms

A saved setup. Somebody writes the instructions once, attaches the material it should work from, gives it a name, and then everybody uses that instead of starting from nothing. Every vendor calls it something different. What has really been captured is one person's way of doing a job, made available to people who did not know how.

Why it matters

Because it is the cheapest way to move expertise around an organisation, and it is also the thing most likely to be quietly wrong six months later. The saved instructions do not know the pricing changed, so the good version of this is a maintained artefact rather than a clever afternoon.

How it works

Instructions, attached material and a name are saved together and reused, which is the entire mechanism. Nothing is trained and nothing is altered about the underlying system, so this is closer to a saved template than to building anything, and the speed of setting one up reflects that.

What actually gets captured is judgement rather than information. The instructions encode which things matter, what to check, what tone to take and what never to do, and that accumulated judgement is why a good one saves far more time than the instructions inside it would suggest.

They decay, and decay is the normal outcome rather than the exception. Prices change, policies change, the attached document is superseded, and the saved instructions keep confidently applying the old world, which is more dangerous than being unhelpful because the answers stay fluent.

The vendors' names for it differ and the shape does not. One product calls them custom versions of itself, another calls them projects, a third calls them agents, and behind all three is a saved arrangement of instructions and material that somebody has to keep current.

Ownership is the variable that decides whether one survives, and it is organisational rather than technical. A named person who reviews it on a schedule is the whole difference between something a team still trusts next year and something quietly abandoned after the first wrong answer nobody could explain.

Two of these, six months on

The pattern is familiar enough to be worth naming plainly. These are trivially easy to create, which means they get created in bulk during the enthusiastic phase, and they contain facts about the world, which means they begin expiring immediately. Nothing announces the expiry. A saved setup carrying last year's pricing answers exactly as fluently as one carrying this year's, and the person asking has no way to tell, so the first wrong answer is usually discovered by a customer rather than by a review. What follows is quiet: the team stops trusting it, goes back to doing the thing by hand, and the entry stays in the list indefinitely because deleting things feels like admitting something. None of this is a limitation of the technology. It is what happens to any shared artefact without an owner, and it is solved the same way it has always been solved.

Seen in the wild

A general assistant offering saved configurations with their own instructions and files, alongside projects that keep related work together.
ChatGPT
An assistant whose projects give a workstream its own workspace, instructions and material that persist across sessions.
Claude
A no-code platform where workers are assembled from tools, triggers and instructions and then deployed against real work.
Relevance AI

Common misconceptions

People assume

It is trained on our material.

In fact

Nothing is trained. Instructions and files are saved and supplied each time it runs, which is why setting one up takes minutes rather than weeks and why changing it is instant. The distinction matters because people extrapolate expectations from the wrong picture, particularly about how much it can hold.

People assume

Building it is the work.

In fact

Building it is an afternoon and keeping it correct is the work. Every one of these embeds facts that expire, and the failure mode is not that it stops working but that it keeps working confidently against a world that has moved on.

People assume

More instructions make it better.

In fact

Past a point they make it worse and harder to fix. Long instruction sets contradict themselves in ways nobody notices until an answer is strange, and a short set covering the decisions that actually recur outperforms an exhaustive one almost every time.

Telling them apart

Custom assistant vs Custom model

Custom assistant

Saved instructions and files, supplied each time.

Custom model

The model itself altered by further training.

One is set up in an afternoon and changed in a minute; the other is a project with a budget, and the names are close enough to be sold interchangeably.

Questions

What makes a good one?: Narrow scope, short instructions and a named owner. The narrowest useful job is easier to describe, easier to check and easier to keep current, and the sprawling one that tries to cover a whole department is the one that becomes unmaintainable first and gets abandoned quietest.
Why did ours stop being useful?: Almost certainly because it embeds something that changed. A price, a policy, a process or an attached document that has been superseded will keep being applied with complete confidence, and nothing about that failure announces itself, which is why a review schedule is worth more than any amount of care at setup.
How many should a team have?: Few enough that somebody can name them all. Organisations that reach dozens generally find most are unused, several are wrong and nobody can say which, and the useful discipline is a short list with owners rather than an open library nobody curates.
Is this the same as what other vendors call projects or agents?: Usually yes, in shape. Saved instructions plus attached material plus a name covers most of what is sold under all three words, so the useful comparison is what each lets you attach and who can see it, rather than which term the product happens to use.