{"slug": "the-six-blank-fields-i-fill-in-before-i-give-an-ai-agent-any-tools", "title": "The Six Blank Fields I Fill In Before I Give an AI Agent Any Tools", "summary": "A developer outlines a six-field task card—goal, may read, may write, ask me before, stop if, show me—that they fill in before granting an AI agent any tools. The approach emphasizes defining narrow, testable goals, limiting data access, and requiring explicit approval before actions, drawing on OpenAI's practical guide to building agents.", "body_md": "*The six blank fields I fill in before an AI agent gets any tools.*\n\nModel choice can wait. Before I connect an AI agent to anything, I open Notes and type this:\n\n`goal | may read | may write | ask me before | stop if | show me`\n\nThat's my whole task card. Six blank fields.\n\nIt 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.\n\nMy first ecommerce automation started with a perfectly sensible idea: automate the thing that was taking the most time.\n\nI 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.\n\nSo 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.\n\nMuch better.\n\nWhen 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.\n\nThat 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?”\n\nTake these two requests:\n\nDraft a reply to this customer.\n\nRead the request, find the order, write a reply, and send it.\n\nThe 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.\n\nOpenAI'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.\n\nHere is how I fill it in.\n\n“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?\n\nI would narrow it to this:\n\nCheck the three product pages I give you, compare today's prices with yesterday's file, and list the differences.\n\nNot exciting, but now the run has edges.\n\nIf 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.\n\nI can add another source later. Taking broad access back after building around it is harder.\n\nThis is the line I used to blur.\n\nReading a price is one job. Changing that price is another. Preparing an email is one job. Sending it is another.\n\nFor 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.\n\nRead-only isn't a demo that gets applause. It is a demo I can actually inspect.\n\n“Ask me if you need to” sounds fine until the agent and I disagree about what “need” means.\n\nI use the actual verb instead:\n\nAnd the pause belongs before the tool runs. A neat explanation afterwards is a receipt, not an approval request.\n\nHappy-path demos make this field easy to forget.\n\nWhat 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.\n\nThis 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.\n\nFor 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.\n\nOther 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.\n\nOtherwise “done” can mean little more than “I have stopped talking.”\n\nThis is the version I would hand over:\n\n```\nGoal\nCompare prices on three supplied product pages with yesterday's record.\n\nMay read\nThe three public URLs and yesterday's local CSV file.\n\nMay write\nOne local Markdown report. No website or store changes.\n\nAsk me before\nThere is no external action in this run, so there is nothing to approve.\n\nStop if\nA page asks for a login, the product match is unclear, the currency is missing,\nor a page still cannot be read after two tries.\n\nShow me\nFor every product: URL, matched name, current price, currency, previous price,\ndifference, and check time. Put failed checks in a separate section.\n```\n\nCould 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.\n\nIf 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.\n\nYesterday's clean run isn't today's permission slip.\n\nI 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.\n\nI 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.\n\nAn 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.\n\nSo yes, pick a model. Just don't make it your first decision.\n\nFill in the six blanks, run the dull version, and keep the send button for yourself until the evidence gives you a reason not to.\n\nThe 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.", "url": "https://wpnews.pro/news/the-six-blank-fields-i-fill-in-before-i-give-an-ai-agent-any-tools", "canonical_source": "https://dev.to/mehmet_kocaba_4dc565d23b/the-six-blank-fields-i-fill-in-before-i-give-an-ai-agent-any-tools-1cji", "published_at": "2026-09-03 23:00:21+00:00", "updated_at": "2026-09-03 23:53:53.576469+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools"], "entities": ["OpenAI"], "alternates": {"html": "https://wpnews.pro/news/the-six-blank-fields-i-fill-in-before-i-give-an-ai-agent-any-tools", "markdown": "https://wpnews.pro/news/the-six-blank-fields-i-fill-in-before-i-give-an-ai-agent-any-tools.md", "text": "https://wpnews.pro/news/the-six-blank-fields-i-fill-in-before-i-give-an-ai-agent-any-tools.txt", "jsonld": "https://wpnews.pro/news/the-six-blank-fields-i-fill-in-before-i-give-an-ai-agent-any-tools.jsonld"}}