Every part of an agentic system lives somewhere: a file the model reads, a skill it loads, a plugin it calls, or custom software around it. Each step up that ladder costs you portability and maintainability. Decide where things live before the vendor does, because their default is the opposite of yours.
An agentic workflow is judgment plus plumbing, and every piece of it has to land somewhere. Where each piece lands is the most consequential architecture decision of the engagement, and it is usually made by default rather than on purpose. The default is predictable: engineers reach for code, and vendors reach for their proprietary layer. Left alone, the build lands a step or two higher on the ladder than it needs to.
The buyer's counterweight is a stated point of view, held before day one. The principle: prefer the layer that the most people can edit, that ports with the least effort, and that the model reads rather than executes.
The Four Steps
Step 1: Files and folders the model traverses. Plain text, model-agnostic, editable by a domain expert with no engineer in the loop, diffable, and cheap to port. Most business knowledge, rules, glossaries, and worked examples belong here. This is also where the eval set lives: the real deliverable of any FDE engagement.
Step 2: Skills. Still text, slightly more structured, scoped to a task. Owned by the orchestrator. Portable across vendors that support the pattern, and trivially converted to plain instructions for those that do not.
Step 3: Plugins and connectors (MCP). Now you are in code. Standardized enough to move between models, but someone has to own auth, API drift, and error handling. Owned by an engineer. Plugins sit above skills because a plugin is typically a bundle of skills plus connectors plus commands: more structure, more code, more coupling. Reach for one when you are packaging something proven, not when you are still figuring it out.
Step 4: Custom software. Orchestration logic, state, bespoke runtimes. Owned by an engineering team, and ported only by rewriting.
Every Step Up Requires a Stated Reason
The first rule that makes the ladder work in practice: nothing moves up a step without an answer to "why can't this be a file?" Most of the time the answer is that it can, and the FDE simply had not considered it. It is the same discipline as the elimination pass in Delete First, Add Second: the cheapest component is the one you never build.
Write the exceptions down. The list of things that genuinely could not be a file, each with its reason, is your architecture document. It is one page, it outlives the FDE and the current model, and it is the first thing the next engineer should read.
Judgment in Files, Enforcement in Code
The second rule: "custom software last" does not mean never, or late. Some things belong in code from day one: anything deterministic, anything with side effects, auth, transactions, hard guardrails. Putting a compliance rule in a prompt because it is faster is the specific tech debt from the buyer's guide, and it is the kind that fails silently.
The Bottom Step Rots Too
One caution before you embrace the files: file-based context rots just like everything else, only quietly. A folder the model traverses is only as good as its hygiene. Assign an owner and a pruning cadence, or in a year the model is reading three contradictory versions of the same policy and picking one at random.
Put the ladder in the kickoff deck and the exceptions list in the working agreement. Both are one-page artifacts, both are cheap on day one, and both are the difference between a build you own and a build that owns you.