When you build a local version of a tool you already use, the temptation is to enumerate its API and reproduce it endpoint for endpoint. The cleaner the original, the stronger the temptation. The instinct feels like respect — you are inheriting from a thing that works, after all. But the instinct is wrong, and the reason it is wrong is worth naming because the same mistake shows up in places that have nothing to do with software.
A workflow’s API is not its experience. The API is the experience plus the constraints of the environment that shipped it. An online collaborative editor cannot see the user’s cursor, so its comment endpoint takes a quoted phrase and resolves the anchor itself.
Move that same comment to an editor where the agent can see the cursor, and the quoted phrase is dead weight — a workaround for a problem the new environment does not have. Port the API and you port the workaround. The error mode the original had to defend against becomes an error mode you have invented for yourself.
The fix is small but not obvious: design the experience first, then reconcile against the source. What would the ideal feel like in this environment, given its actual affordances? Only then ask which of the source’s primitives are still load-bearing and which were workarounds for the environment you have left behind. The honest classification has three buckets: still required, replace with native primitive, drop entirely. Most porting projects skip the middle one.
The same shape shows up wherever something travels. Frameworks moving between teams. Processes moving between organisations. Regulations moving between jurisdictions. Each port carries the constraints of the source, and each one is a place where the importer has the opportunity to ask whether the constraint still applies, or whether they have just inherited a defence against a danger they no longer face.