How to Build an Order-Lookup and Status AI Agent (Read-Only)

An order status AI agent answers 'where's my order?' on demand -- it looks up the order, reports the status, and shares tracking, without a human digging through records for the hundredth time this week. It is also the single best first agent to build, because it is read-only: it looks, it never touches. That makes it nearly impossible to get wrong, which is exactly why it is a clean way to learn the permission grid.

You build it as a no-code agent in the AI Assistant, pointed at your order data with read and nothing else. This guide walks that build and uses it to teach the grid, so the agent you ship also doubles as the mental model for every riskier agent you build next. For the full step-by-step of the builder itself, how to build a custom AI agent is the flagship guide.

The scariest thing about giving an AI access to your business is the thought of it changing or deleting something. A read-only agent removes that fear entirely: it can look at orders and stock, and it cannot alter a single record. Worst case, it reads something it should not have surfaced -- which you control with identity rules -- but it can never break your data.

That safety makes it the ideal teaching case. You will set every write, delete, and send to off, and every read to allow, and watch a genuinely useful agent emerge from the most conservative grid possible. Once you have seen how much value a look-only agent delivers, the grid stops being abstract, and you will know exactly which additional verbs a future agent actually needs -- and which it does not.

Create the agent -- 'Order Status Lookup' -- and brief it on what counts as an answer. Tell it what an order record contains, what the statuses mean in your business ('processing' vs 'fulfilled' vs 'backordered'), and how to phrase an update to a customer clearly. Tell it what to do when an order cannot be found: ask for a different identifier, or hand off, rather than guessing.

Give it the boundaries too. It reports status; it does not promise a delivery date it cannot verify, and it does not offer to change, cancel, or refund the order -- those are out of scope for a read-only agent, and it should say so and route the request onward. A tight brief here keeps the agent helpful without wandering past what its permissions allow.

Grant the agent POS so it can read orders, and Inventory if it should also answer stock questions like 'is this back in yet?' Then set the grid to the simplest configuration there is: read -- allow, on orders and stock. Write -- off. Delete -- off. Send -- off. Every verb except read is switched off.

That is the whole grid, and it is worth sitting with, because it is the shape every safe agent starts from. You are not trusting the agent with your data; you are lending it a window into it. Nothing it does can propagate. If you later want it to email a status update rather than just answer in the conversation, that would be an external send -- which stays on the approval floor -- but for a first agent, keep it look-only and let it answer where the customer is asking.

Read-only does not mean 'show anyone anything.' Order data is customer data, so tell the agent how to verify who it is talking to before it reveals details. On an authenticated channel, it knows who the customer is. On a public channel, it should ask for an order number plus a matching identifier before sharing anything specific, and reveal only that customer's own order -- never browse.

This is where a read-only agent still needs care, and it maps to a platform default: a public web agent is read-only until you deliberately open it up, precisely because reading the wrong data to the wrong person is the main risk when writing is off the table. Brief it to protect customer information the way a good front-desk person would -- helpful, but not handing order details to whoever asks.

A read-only agent will regularly hit requests beyond its scope -- someone wants to change an address, cancel an order, or get a refund. That is by design, and the agent should handle it gracefully: explain that it can look things up but cannot make changes, and route the request to a human or the right flow.

Anything that would change the order is a write, and anything financial is money movement on the high-risk floor -- both out of bounds for this agent. So it defers, and on a public channel with an anonymous visitor, defer-and-report is the only safe move anyway, since a stranger can never approve a high-risk action. Frame the handoff as helpful, not a dead end: 'I can see your order is processing; to change the address I'll pass you to the team.'

Order-status questions come in wherever customers already are, so meet them there. A public web link is a natural fit, since read-only is the default for public agents anyway -- you are not loosening anything to deploy it. Add SMS or phone via the Communications add-on if customers text or call to check on orders. Or keep it internal so your staff can ask instead of digging through records themselves.

Because it is read-only, you can be comfortable letting it run unattended from day one -- there is no risky action to supervise. Start it live, watch its lookups, sharpen the brief where it phrases something poorly, and when you are ready for an agent that also acts, you will build it on the exact grid discipline this one taught you.