# The Six Blank Fields I Fill In Before I Give an AI Agent Any Tools > Source: > Published: 2026-09-03 23:00:21+00:00 *The six blank fields I fill in before an AI agent gets any tools.* Model choice can wait. Before I connect an AI agent to anything, I open Notes and type this: `goal | may read | may write | ask me before | stop if | show me` That's my whole task card. Six blank fields. It looks almost too plain to be useful. Still, it has saved me from handing a clever system a foggy job and far too many keys. My first ecommerce automation started with a perfectly sensible idea: automate the thing that was taking the most time. I got as far as mapping it out, then scrapped it. The job wandered into payments and refunds. If the workflow made a bad call, undoing it would be awkward at best. The fact that the answer might look polished didn't help. So I went backwards and picked something boring. The system drafted replies to common customer messages. I read them. My hand stayed on the send button. Much better. When a draft was off, I saw it first. No customer had to point out the mistake. Nothing had moved in the store. There was no transaction to reverse. That changed the question I ask at the start. I don't begin with “Which model?” anymore. I begin with “Which doors am I about to open?” Take these two requests: Draft a reply to this customer. Read the request, find the order, write a reply, and send it. The first one can finish as text on your screen. The second needs access to customer data, order data, and an outbound channel. One extra verb, “send,” changes the job. OpenAI's [practical guide to building agents](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/) breaks the basic setup into a model, tools, and instructions. It also says to check whether ordinary deterministic software would do the job before you commit to an agent. Both points are useful. I just add a scrappy permission note beside them. Here is how I fill it in. “Watch my competitors” isn't a goal I can test. I can already hear the follow-up questions. Which competitors? What should be watched? Since when? Where does the result go? I would narrow it to this: Check the three product pages I give you, compare today's prices with yesterday's file, and list the differences. Not exciting, but now the run has edges. If the job needs three public URLs and one local CSV, I write down those four sources. I don't hand over a Drive account on the off chance that it may be handy. It doesn't need my browser history either, or a customer list, or the store admin panel. I can add another source later. Taking broad access back after building around it is harder. This is the line I used to blur. Reading a price is one job. Changing that price is another. Preparing an email is one job. Sending it is another. For an early run, “may write” usually means one local report on my machine. The agent can leave evidence there. It can't update the CRM, edit a product, publish anything, or contact anyone. Read-only isn't a demo that gets applause. It is a demo I can actually inspect. “Ask me if you need to” sounds fine until the agent and I disagree about what “need” means. I use the actual verb instead: And the pause belongs before the tool runs. A neat explanation afterwards is a receipt, not an approval request. Happy-path demos make this field easy to forget. What happens when the price is missing? What if two products have nearly the same name? What if a page throws up a login screen? I don't want the agent to improvise its way into a wider scope. I want it to stop, point at the snag, and leave the rest alone. This is also where I put a retry limit. Two failed reads is enough for the small pilot below. The third attempt probably won't become wiser just because it is the third. For a price check, I want the URL, product name, price, currency, previous value, and check time. If the page failed, I want that in the same report. Other jobs leave different proof: a saved file, a patch that passed its test, a message identifier, a record in the system's history. The shape changes. The rule doesn't. We agree on the evidence before the run starts. Otherwise “done” can mean little more than “I have stopped talking.” This is the version I would hand over: ``` Goal Compare prices on three supplied product pages with yesterday's record. May read The three public URLs and yesterday's local CSV file. May write One local Markdown report. No website or store changes. Ask me before There is no external action in this run, so there is nothing to approve. Stop if A page asks for a login, the product match is unclear, the currency is missing, or a page still cannot be read after two tries. Show me For every product: URL, matched name, current price, currency, previous price, difference, and check time. Put failed checks in a separate section. ``` Could it still misread a number? Of course. This card doesn't make failure impossible. It keeps the failure inside a report, where I get to spot it before it turns into a store edit. If the reports hold up, the next version may prepare a change proposal. That means a new card. Letting it touch the live store would be another new card. Yesterday's clean run isn't today's permission slip. I don't build an agent to polish one paragraph. A chatbot is enough for that. I give it the paragraph, read the edit, and choose what stays. I also skip the agent when a small, fixed “if A, then B” automation will work. Plain rules are often easier to read, test, and repair. An agent starts to make sense when the job has several steps and the next step depends on what it finds. Even then, I start with the smallest useful loop. Usually read-only. I test the stop condition on purpose. Only then do I open another door. So yes, pick a model. Just don't make it your first decision. Fill in the six blanks, run the dull version, and keep the send button for yourself until the evidence gives you a reason not to. The original English guide is on [MehmetKocabas.com](https://www.mehmetkocabas.com/en/blog/what-is-an-ai-agent), which is my site. I wrote this DEV adaptation around the six-field card and the low-risk pilot.