The same capability, built as a feature or built as a tool, differs by an order of magnitude in long-term value.
A feature can only be clicked. It lives at a particular spot on a particular page, with its own button, form and results area. The user has to know where it is, go there, and use it.
A tool can be called. It has a name, parameters and a defined return, and anything can call it — your own agent, another assistant the user installed, a partner's system. It doesn't require anyone to find it first.
In the agent era, that difference decides how far your capability can travel.
One definition, two exits
The easiest mistake when building tools is two implementations.
The internal agent uses one; opening up externally gets a second interface written for it; and the two slowly drift apart — parameter meanings diverge, edge cases disagree, a change on one side is forgotten on the other. Six months later nobody dares touch either.
The right shape is one definition, two exits. A tool is defined once: what it does, what it takes, what structure it returns, what error it raises when. Internal orchestration calls it; the external protocol exposes the same thing.
There's a concrete side benefit: because an external caller is a stranger, you're forced to write each tool's semantics precisely. And that precision makes your own agent more accurate — vague tool descriptions are the number one reason an agent picks the wrong tool.
Grade by read/write, not by importance
Opening up doesn't mean opening everything.
My split is simple: read tools can be public; write tools stay inside our own permission ring. Query history, search, estimate, analyze — worst case someone queries a few more times. Create an order, change a state, send a message — not public, or public only inside a full authorization chain.
Don't grade by "importance." The important tools are often exactly the ones worth opening, because they're what proves your data is worth something. The real line is whether this call changes the world.
Not every question deserves the deep path
Once you have a pile of tools, the next question is when to use them.
Send every question down a multi-tool deep chain and cost and latency go out of control immediately; answer everything in lightweight mode and complex tasks are useless. So you route: simple questions get answered directly, complex tasks get planning, parallel retrieval and assembled delivery.
Routing is a product decision, not just a technical optimization. It determines whether a sentence takes three seconds or thirty, and those two experiences serve completely different situations — the three-second one gets used casually; the thirty-second one has to be worth the wait.
Memory: across sessions, append-only, isolated per person
Tools let an agent do things. Memory keeps it from starting from zero every time.
Three principles I consider non-negotiable:
- Across sessions. All of memory's value is between sessions. When the same user comes back, the system should know what they cared about, what format they prefer, which language they use.
- Append, don't rewrite. New preferences supersede old ones, but don't let the system "correct" history. A system that edits its past can't explain itself.
- Isolated per person. Read and write boundaries follow user identity strictly. In a multi-tenant setting this is a red line, not an optimization.
One more lesson: memory needs a rolling window. Infinitely accumulated context isn't smarter, it's more expensive and easier to derail with irrelevance.
Boundaries
Not every capability should become a tool. Things used exactly once, logic tightly coupled to one page, semantics you can't state clearly — forcing these into tools just makes the list longer. And a longer tool list raises the chance the agent picks wrong, which is a real cost.
Opening up is an operation, not a release. Once it's out you need account authorization, subscription checks, quota management and call logs, or you won't know who's using it, whether they're using it correctly, or whether it should be billed. Throwing tools over the wall and walking away is the same as not doing it — except now you have a traffic source you can't explain.