Cenk

Worth adding the measurement question, because otherwise you are working blind on this.

You can already see some of it. Assistant and agent traffic arrives with recognisable user agents and, increasingly, from identifiable address ranges. Segment your logs by that and you will have a number for how much of this is reaching you today.

For most small shops that number is currently small. It is also the number that tells you when to care, and watching it costs an hour of log work rather than a subscription.

Also worth checking whether referrals from assistant products appear in your analytics at all — attribution here is genuinely poor, and a share of what looks like direct traffic is somebody acting on an assistant's recommendation.

One low-effort thing that changed behaviour on my team more than any tool: make the safe path faster.

We added a one-key command that copies the current log with secrets already scrubbed. People use it because it is less work than selecting the text by hand, not because of policy.

Security measures that add a step lose to convenience every time. Ones that remove a step win without needing anybody to agree with them.

One thing worth deciding early, because it changes the whole design: are you retrieving or are you reading?

Reading means one page, now, into context. Then you want the full cleaned markdown and chunking is irrelevant. Cheap and easy.

Retrieving means a corpus you search over later. Then chunking, embedding, storage and the freshness question all appear, and it is a much bigger commitment.

A lot of teams build the second when they needed the first. If your agent looks at a page because a user mentioned it, you do not need a vector store — you need a fetch and a clean-up. That distinction has saved me more work than any tool choice.

There is no accepted standard, and the practical answer is the boring one: keep it yourself, in plain files, in version control.

What has actually converged is a convention rather than a format — most coding assistants now read a markdown instructions file from the project root. The filenames differ, and the content is just prose, which means one file plus a symlink or a small copy step covers several tools.

So the portable layer already exists and it is markdown in a repository. What is not portable is everything held inside a vendor's account: conversation history, tool configurations, memory features, custom instructions set in a web interface.

My rule after being burned twice: anything I would mind rewriting goes in the repository. If it only exists in a product's settings page, I treat it as disposable.