When a kit is 80% of what you need
The kit does most of the job and gets one thing wrong. What you can change after installing, what you cannot, and when to start from scratch instead.
You find a kit that does the job, except it categorises into four buckets and you need five. Or it drafts in a register that is not yours. Or it wants Write on the CRM and you would rather it did not touch the CRM at all.
This is the common case, not the exception, and it has a better answer than either settling or starting over.
What you can and cannot change
Taking a kit mints a worker in your account. The kit was the recipe; the worker is yours, which decides most of this table.
| Yours to change | Fixed | |
|---|---|---|
| The instruction | Yes, it is your worker's | |
| App access levels | Yes, per app, any time | |
| The schedule or trigger | Yes | |
| Which provider fills an open slot | Yes, at install | |
| The model | Yes, any time | |
| Memories | Yes | |
| The kit's public page | Belongs to the publisher | |
| The kit's own future updates | The publisher's | |
| Other people's installs | Theirs |
The short version: everything about how your worker behaves is editable. What you cannot edit is the published artefact other people install.
The four options, in order of cost
| Option | Cost | Right when |
|---|---|---|
| Use it as-is | Nothing | The 20% does not actually matter yet |
| Narrow the access | A minute | It asks for more than your job needs |
| Edit the instruction | An hour, plus a week of receipts | The logic is close but not yours |
| Build from scratch | A day, plus weeks of tuning | The job is genuinely different |
Most people jump from the first to the fourth. The middle two are where the answer usually is.
Start by using it as-is for a week
Counterintuitive and usually right. The gap you noticed while reading the kit page is a prediction, and predictions about your own edge cases are frequently wrong.
Run it read-only for a week and read the receipts. Two things happen often enough to be worth waiting for: the thing you were going to fix turns out not to matter, and something you had not noticed turns out to matter more. Editing before you have that evidence means editing on a guess.
Narrowing access is the cheapest real change
If a kit asks for more than your version of the job needs, refuse it. The app firewall grants access per app and per level, and the worker keeps running with whatever is left, recording on its receipt what it could not do.
That is a genuinely underused move. Take CRM Scribe, which reaches email, meeting notes and the CRM. If you want the meeting summaries but not the CRM writes, set the CRM to Off and see what the worker still produces. You have not broken it; you have made a narrower worker out of a broader kit, in about a minute, reversibly.
Editing the instruction
This is the main event, and the discipline is to change one thing at a time.
The instruction is yours after install, so you can add your fifth category, your register, your escalation rule. What makes this go wrong is editing five things at once and then being unable to attribute a behaviour change to any of them.
A workable loop:
- Change one rule.
- Let it run a few days.
- Read the receipts for that specific behaviour.
- Keep or revert, then change the next thing.
Prefer adding a rule to the existing instruction over rewriting it. The kit's instruction encodes edge cases its publisher hit over many runs, and a rewrite throws that away to fix one thing you noticed on day two. That inherited experience is most of what you installed a kit for.
The failure mode: the ship of Theseus worker
Six months of one-line edits and the worker's instruction has nothing in common with what you installed. It still carries the kit's name in your fleet list, so everyone assumes it does what the kit page says, including you when you come back to it after a quarter.
Two consequences. Nobody can reason about the worker from the kit page any more, and when the publisher improves the kit you have no way to take the improvement, because your version diverged silently.
The tell is straightforward: if you can no longer describe your worker using the kit's job sentence, it is not that kit any more. At that point either rename it in your own fleet so nobody is misled, or build the thing you actually have as a private kit and be honest that it is yours.
When to build from scratch instead
Editing wins right up until it does not. Start over when:
- The job sentence is different. Not "the same job with a tweak" but a different job. Rewriting an instruction to change what a worker is for is slower than writing one.
- You are fighting the structure. If most of your edits are removals, the kit is solving a bigger problem than you have.
- The apps are wrong. A kit built around a CRM, used by someone with no CRM, is not 80% right. It is a different worker that happens to share a verb.
- You would ignore most of it anyway. If the useful part is one paragraph, take the paragraph and write your own.
The Kit Creator Studio is a no-code builder, and building from scratch is not the expensive option people assume. Describe the job, pin the apps and the access, write the instruction, validate. The expensive part is not the building, it is the weeks of receipts that teach you what the instruction is missing, and that cost is the same either way. What a kit saves you is somebody else having already paid it.
The reasonable objection
"If I have to edit the instruction anyway, what did the kit actually give me?"
The edge cases you have not hit yet. A kit's instruction is a record of what surprised its publisher across many runs, and on day two you have hit none of them. Your five edits address what you noticed; the twenty rules you did not write address what you have not.
That is worth being precise about, because it is the whole value proposition. A kit is not a shortcut to a working prompt, which you could write yourself in ten minutes. It is a shortcut to a tested one, and testing is the part that takes weeks.
When 80% is simply enough
Worth saying, because the instinct to close the gap is strong and often wrong:
- The missing 20% is work you were not doing anyway. A worker that handles four of five categories is four categories better than the status quo.
- The gap is cosmetic. Register and phrasing matter less than people expect on internal output.
- You are still evaluating. Do not tune a worker you have not decided to keep.
- The 20% needs judgement. If the part it gets wrong is the part requiring a human, leaving it for a human is the correct design rather than a shortfall.
FAQ
Can I edit a kit's instruction after installing it?
Yes. Taking a kit mints a worker in your own account and the instruction is then yours, along with the access levels, the schedule and the model. What you cannot change is the kit's public page, which belongs to its publisher.
What if a kit asks for more access than I want to give?
Refuse it. Access is granted per app and per level, so you can set an app to Off or Read and the worker keeps running with whatever is left, recording on its receipt what it could not do. It takes about a minute and is fully reversible.
Should I edit a kit before or after running it?
After, and after a week of read-only runs. The gap you notice on the kit page is a prediction about your own edge cases, and it is often wrong in both directions: the thing you meant to fix does not matter and something else does.
Do I lose the publisher's updates if I edit my worker?
Your worker runs the instruction you have, so publisher updates do not overwrite your edits. The trade is that a heavily edited worker has diverged, and taking a future improvement means merging it by hand.
When should I build a kit from scratch instead of editing one?
When the job sentence is genuinely different, when most of your edits are removals, or when the apps are wrong. Building in the Studio is not the expensive part; the weeks of receipts that teach you what the instruction is missing are, and a kit is a shortcut to somebody else having already paid that.