# Using agents right Over the last two years there has been no shortage of advice on using agents properly. A workflow. A test-first rule. A team of agents with job titles. A loop that runs all night. An approval prompt at every step. A plan hundreds of lines long. A rule file that grows every week. They were all built to avoid one thing: **asking what you actually want.** > "We write tests first. So, what are you building?" Agents today read a codebase, find their way around it, run the tests, and fix what breaks. A year ago someone had to sit next to them and spell out every step. When it comes to how the work gets done, the order an agent picks for itself now beats the one you would write for it. We still teach them the way we did a year ago. Read in this order. Write the tests at this step. Split it this many ways. That isn't just wasted effort. It makes the agent worse at the job. That way of working belongs to weaker models. Every time a model got something wrong, someone added a rule, and the rule file became a list of old failures. A newer model gets tied up in all those patched-on constraints and never shows what it can do. **The workflow you run today becomes legacy the day the next model ships.** Meanwhile the way agents fail hasn't changed. You ask for one bug fix and it rewrites the payment logic that was working fine. You ask it to tidy up and it deletes data you were still using. It never asks whether that was okay. A better model does the same. What the agent lacks isn't know-how. It's your intent. ## Now they say humans are the bottleneck Agents got fast. People run several at once, leave them going overnight, and collect the results in the morning. So a new line started going around: the slow part now is the human. The person who has to review and approve everything the agents produce. Everyone now works to keep people out of the loop. Agents run alone for longer, tasks get chopped smaller, other agents do the review, approvals get batched into one sitting. The human got swapped out for process. Teams force TDD on everything without knowing what TDD is for, and when a graph of subagents handing work to each other lights up the screen, they take it as a sign things are going well. ## The bottleneck isn't at the end Why is there so much to review? Why does the agent keep stopping halfway to say "I need a decision"? Because nobody got clear on what you wanted before the work began. So the human has to go through every result afterward to check it, and the agent has to come back and ask every time it gets stuck. Intent that was never drawn out at the start shows up later as a bottleneck. Tools do ask questions now. Most of them are fixated on the wrong thing. They treat the number of questions as a measure of care, or they tell the agent "you are the PM" and "you are QA." Changing costumes doesn't tell anyone what you meant. Go back through the twenty questions you got. Most of them (which framework, which database) could be answered by opening `package.json`. The one thing the agent doesn't know is your intent, and that is exactly what it skips. Will fewer check-ins help? No. They make it worse. The longer an agent runs without knowing the intent, the further off it goes, and what you collect in the morning is more output that misses by more. The review queue only grows. **The bottleneck isn't the human. It's the intent nobody asked about.** ## Where Dryforge starts Dryforge goes the other way. Instead of keeping people out, it gets their intent up front. It doesn't script how the agent writes code, and it doesn't make it role-play a PM or a QA engineer. Reading the code and building it are the agent's call. That is what models do best, and the calls get better on their own as models improve. Dryforge holds one rule fixed: every decision belongs to someone, and Dryforge settles who. Beyond that rule it fixes only the minimum needed to keep it, and leaves everything else to the agent. A better model doesn't change who gets to decide, so the rule doesn't go stale. Everything below follows from it. ### Some decisions are yours How to read the code, what order to build in, where tests go and how many, whether to split the work: those are the agent's decisions. It makes them better than you would, and better still with every new model. What you want is something the agent can never decide. Whether to issue a refund, whether a deleted post comes back, whether slow and exact beats fast and approximate. No model, however good, knows that. Only you do. Right now this is upside down. People are busy choosing methods and reviewing results, and agents fill the empty space where intent should be with guesses. Once the intent is clear, the agent picks the method on its own. In Dryforge, a decision that's yours comes back to you, even when it looks like a technical detail. The agent makes its own calls with everything it knows. **Intent decides the method. Never the other way around.** ### Intent is tacit knowledge The trouble is that your part is harder than it sounds. You don't fully know what you want. You do know it, you've just never put it into words. You know more than you can tell. That is tacit knowledge. Someone who wants a message board has a picture of one screen in their head. Whether a long list paginates or scrolls forever, whether a deleted post is really gone or just hidden: none of that is in the picture. They've never thought about it, but they do have an answer. They find out when they see the finished thing and say "that's not it." A one-line prompt can't carry that, and neither can a spec hundreds of lines long. Nobody is being lazy. These things have simply never been said out loud. And those are usually the things that decide the outcome. So Dryforge doesn't take dictation. It draws the intent out, because intent you don't know yet can't be dictated. ### The scariest thing is a default nobody chose The scariest decision is the one that went by without a question. A default nobody stated, settled quietly: whether refunds are allowed, where deleted posts go, which requirement wins when two collide. The agent fills these in with something plausible and moves on, and you find out much later from a customer support ticket. No amount of review later will catch a default like that. The code runs. The tests pass. Nothing is broken except a decision nobody knew was made. The only place to catch it is before it's made, by asking the person it belongs to. So Dryforge changes how the questions are asked in the first place. A good question puts that default in front of you. Dryforge reads the project first and doesn't ask what it can look up, because your attention is too expensive to spend on what the agent can find itself. Then it finds what you didn't say but someone still has to decide, and puts it in front of you. It's the question that gets you to say "huh, I hadn't thought of that." Technical calls come to you too when you'll have to live with them, with a recommendation attached so you don't need to be an engineer to choose. The pointless questions disappear, and each one that remains changes the result. Every question Dryforge asks is there because the decision is yours. ### You decide only what you must Once the intent is drawn out, there isn't much left for you to decide. You approve what you decided, all in one place, and from there the agent chooses the method and works at full strength. Telling it how would only get in the way. Agents already push ahead on their own. The problem is that they do it however they like. They fill anything nobody decided with a plausible guess and settle what you meant for you. Three months later, nobody can say why the code looks the way it does. In Dryforge, the agent acts on its own only inside the intent you approved. It makes the calls that are its to make, and never guesses the ones that are yours. If building reveals that something you approved has to change, it doesn't quietly bend the intent. It stops and asks you. Since the intent was settled at the start, that is rare. Apart from real blockers, it doesn't come to you with anything that isn't yours to decide. Done means it actually ran. The agent's word doesn't count. So at the end there is no need to take the result apart piece by piece. You only check that it came out the way you decided. The time that went into review goes into decisions instead. --- Used this way, agents let you do what you couldn't do alone. That was always the point of using them. They will keep getting better, and an agent that gets faster without knowing your intent only builds the wrong thing faster. **Using agents right comes down to one thing: making them ask the right question.** Dryforge is a plugin you add to your agent. Throw whatever you want built at `ready`, approve the intent it hands back, then run `go`. Try it. The first thing you'll get is a question you hadn't thought of.