Design It Against the Constraints or Design It Twice

The order matters more than the content. Every regulated institution eventually learns what its compliance and model risk functions need to see. The only question is whether it learns that at the whiteboard, or at the approval gate after it has already built something else.

That claim has a strong objection and it deserves a better answer than a comeback: you cannot govern what you have not designed, so redesign the process first and govern it after. The objection came from a CTO who operates companies for a living. It is the best argument against everything I write.

It also deserves to win the parts it wins.

He is right about the sequence of understanding

You cannot write controls for a workflow that does not exist. Design is the first act. Anyone who has sat in a governance forum reviewing a use case that is still a slide knows what governing the abstract produces: policy nobody can execute, controls attached to nothing, a document that ages badly the moment real work begins. John is right that the redesign of the process is where the value is created, and right that a governance function with nothing concrete in front of it mostly generates friction.

If the argument ended there, governance first would lose. It does not end there, because of one word: when.

Wrong in one specific way

In a regulated firm, the constraints are not a filter you apply after the design. They are an input to it. No engineer designs a bridge and then walks it over to a load limits department for review. The limits are in the drawing from the first line, and nobody calls that bureaucracy. It is simply what designing a bridge means.

Agent workflows in a regulated institution are the same object. There are exactly two moments to learn what compliance and model risk need to see: at the whiteboard, or at the approval gate after you have built the wrong thing. The knowledge is identical in both cases. The price is not.

The approval gate is the most expensive classroom in the institution

I have watched the second path more than once, and it always runs the same way. A team designs a genuinely good agent workflow in isolation. The demo lands. Then it meets review, and the questions begin. Where is the audit trail. Who is accountable at the decision point. Which of this data are we licensed to use this way. What is the model risk rating. None of these are paperwork questions. Every one of them is an architecture question, and the answers were not designed in.

So the team designs it twice. Once for the demo, once for the regulator. The rework is the visible cost, and it is the smaller one. The larger cost is trust: a sponsor who watched the momentum die, a control function that now expects to be surprised, a delivery team that walks away having learned the wrong lesson. They conclude that governance kills projects. What actually killed the project was meeting the spec at the gate instead of the whiteboard.

What day one looks like instead

When we shipped a production compliance agent inside the compliance function of a global systemically important bank, the control functions were in the room in the first week. The procedure was codified before the agent ran it. A human stayed the decision maker. The retrieval was grounded so it could not invent a source, and every step wrote an audit trail. Model risk management later rated it low risk, not by concession but by design, because the constraints had been load limits in the drawing, not objections at the gate.

We did not do it that way because it was virtuous. We did it because it was faster. The approval that usually takes the longest is the one you start earning after you finish building.

We are describing the same hire

Here is the part I want to concede back to John, because the disagreement is smaller than it looks. The person he wants first, the one who redesigns the process, and the person I want first, the one who makes yes safe, are the same hire. He names them by what they build. I name them by what they clear. In a regulated firm you cannot have one without the other, because the constraints are part of the process being redesigned, and a redesign that ignores them is a first draft wearing a launch date.

The test you can run on Monday

There is a fast way to find out which path a workflow is on, and it takes one meeting. Pick any agent initiative currently in design and ask the team two questions. Has model risk seen the drawing yet, not the demo, the drawing. And can you state, today, what the audit trail will show for the most consequential decision this workflow makes. Teams on the first path answer both in a sentence, because the answers are in the design. Teams on the second path explain why it is too early to say. It is not too early. It is the exact moment the second design is quietly being scheduled.

The position I hold

Every agent workflow in a regulated institution will meet the constraints eventually. That is not a choice anyone gets to make. The only choice is when, and the two options are priced very differently. Meet them at the whiteboard and they are requirements. Meet them at the gate and they are rework, plus the trust you burned being told no.

Design it against the constraints, or design it twice.

John, if this still reads backwards from where you operate, say so. The argument got better the last time you pushed on it.