Giving an AI Assistant Your QR Codes: What It Can and Cannot Do

The job it is best at: retargeting a printed batch

A dynamic QR code resolves through a redirect, which means the sticker on the table never changes but the address behind it can. That is the whole reason to print one. The tedious part has always been the middle: finding the forty codes from last autumn’s campaign, checking which ones are still live, and changing them one at a time without touching the thirty that should stay put.

That is a conversation, not a form. You describe the batch, the assistant lists exactly which codes it matched and where each one currently points, and you say yes or correct it before anything moves. The change then takes effect for the next person who scans — including the sticker already on a table, which is the part worth saying out loud before you press.

• Ask in your own words; confirm against a list before anything changes
• Static codes are named as needing a reprint rather than failing one by one
• A published code changes for everyone who scans it next

The second job: the report nobody writes

Scan analytics are easy to look at and hard to summarise. A weekly report means comparing this period against the last, putting names to the codes that moved, and saying what to do about it — which is the part that gets skipped when it is a manual job every Monday.

An assistant reads the same numbers your analytics screen shows and writes the summary. What matters is that it reads them honestly: a code with zero scans is only unused if it is dynamic, because a static code cannot be measured at all. That distinction is built into how the assistant is told to answer, so a silent static code is reported as unmeasurable rather than as a failure.

What it will not do, and why that is deliberate

The interesting part of connecting an assistant to a business is not the list of things it can do. It is the list of things it cannot, and whether those limits were chosen or simply not built yet.

It cannot read what your customers wrote. A feedback survey returns scores, counts and the spread of answers per question — never the sentences somebody typed. Those are read by a person in your inbox, because a sentence a customer wrote is not yours to hand to a third system, and a reply sent to a credential lands wherever its holder stores it.

It cannot delete a code. Destroying the redirect behind something already printed cannot be undone, and that is not a confirmation an assistant gives on your behalf. It is offered archiving instead, which stops the code resolving and reverses when you change your mind.

It cannot quietly change things. Every tool that writes is marked as writing, which is what makes the client stop and ask you first; archiving is marked harder still, because it is felt outside the workspace.

• Survey comments: never returned to any key or assistant
• Deleting a printed code: not offered — archiving instead, and it reverses
• Writing: always flagged, so your client asks before it acts

Give it less than you think you need

Access is granted by scope, and the assistant is only shown the tools its scopes allow. A key that can read codes and analytics cannot create one — and more usefully, the create tool is not in its list at all, so it never proposes something it would then be refused.

Start read-only. Ask it for a report, watch how it reasons about your data for a week, and widen the key when you know what it does with what it has. This costs nothing: a second key with write scopes is a minute of work, and the first one keeps being useful.

• Read-only first: reports and lookups, nothing that changes
• Widen to writing once you have seen how it works
• A tool outside the scope is invisible, not merely refused

Two ways in, and what each is for

A tool you run yourself takes an API key: create one, paste the address, done. That is the right route for a desktop assistant on your own machine, where you control the credential.

A connector from somebody else’s directory uses a sign-in flow instead, and you never handle a key at all. Before anything is granted you see who is asking, which workspace it would reach and what it would be able to do — and only an owner or admin can approve it. Either way the connection is listed in your workspace and can be cut off in one press.

Questions worth asking of any product, not just this one

Assistants are being connected to real businesses faster than the habits for doing it safely are forming. The useful questions are the same whoever built the integration.

Can you see what it was granted, after the fact? Can you revoke it in one place? Does it say what it cannot do, or does it discover that halfway through a task? And when it touches something a customer wrote, or something printed and already in the world, does the product treat that differently from an ordinary record?

• Is the grant visible and revocable after the fact?
• Are the limits stated up front or discovered mid-task?
• Is customer-written text treated differently from your own data?