Where Impossible Starts Becoming a Plan

I was told a Salesforce archive couldn't be done. The data was too tightly integrated, everything touched everything, and the org was going to have to live at 120% of its storage allocation.

I split it apart.

About 90% of it could be isolated within days, once somebody sat down and worked out which records genuinely depended on which. That work took the org's storage from 120% down to 70%.

I want to be careful about what that story proves, because it isn't that I'm clever. Every financial system on earth has to solve this at archive time. The pattern was sitting there. Nobody had decomposed the problem, so the whole thing wore the label "impossible," and the label stuck because nobody had a reason to test it.

That is almost always what impossible means. It's a diagnosis of effort, not of reality.

The lesson was never about archiving

It was about context.

When every part of a problem is treated as inseparable, the system gets heavy. That's true of a Salesforce data model, and it turns out to be just as true of an AI agent.

The context-engineering research keeps arriving at the same practical answer, which is not a subtle one: give each worker the evidence and the authority it needs for its part of the job, then make the handoff explicit. That's it. That's the finding. It reads like something a project manager would say in 1985, and it is currently one of the more useful things you can know about building agent systems.

In practice, for an agent system, that looks like separation of duties:

• Intake defines the request, and nothing else.
• Retrieval gathers the evidence.
• The builder works inside a narrow boundary.
• A verifier inspects the artifact against the goal, and has the standing to reject it.
• The orchestrator keeps the decisions and the exceptions visible.

The important word in all of that is artifact. Each stage should pass something concrete forward: a document, a diff, a record, a structured result. Not a vague promise that the work was handled. A promise can't be inspected, and anything you can't inspect, you can't debug at two in the morning.

Salesforce architects already do this instinctively, we just don't call it context engineering. A validation rule is a verifier. A permission set is a boundary. An approval process is an explicit handoff with an artifact attached. The platform has been enforcing this shape for twenty years.

Decomposition is the same skill whether the worker is a table, a service, or a model.

The catch

Decomposition creates coordination cost, and I've watched people walk straight into that wall.

Five poorly bounded agents will create more confusion than one overloaded agent. You've replaced a slow, legible problem with a fast, illegible one. The boundaries, the handoffs and the stop conditions are the architecture; if you split the work without designing those three things, you haven't decomposed anything, you've just distributed the mess.

There's a second trap that's easier to fall into now. Context windows keep getting bigger, and a bigger window will happily hold more of the mess. That feels like a fix. It isn't one. It raises the ceiling on how much disorder you can carry before it becomes visible, which mostly means you find out later, with more of it.

The same thing was true of that archive. The org could have bought more storage. It would have worked, for a while, and the underlying model would have kept getting heavier, and the eventual conversation would have been worse.

Where to start

Take the thing on your list that somebody has told you can't be done, and don't argue with them about whether it's possible. Ask a narrower question instead: which 10% of this is genuinely inseparable?

Usually you'll find the answer is smaller than the reputation. And once you can name the part that's actually hard, the rest of it stops being a wall and starts being a list.

That is usually where impossible starts becoming a plan.