Superintelligence Prep for Screen Printing Shops: Artwork and Reorders

A screen printing shop can give an AI agent real responsibility only after its records answer three questions without someone searching email: which artwork revision the customer approved, which screens exist for that job and where they are stored, and when the next reorder of a repeat design is due. Those records are artwork version control, screen reuse records and reorder reminders. Build them first, and the agent has reliable facts to act on, which is what makes each later step safe.

Key takeaways

• Artwork version control decides which file is current, so an agent should never choose between two approved proofs.
• Screen reuse records connect each design revision to the physical screens, colors and mesh counts that produce it.
• Reorder reminders work only when one named record owns the schedule and duplicate sends are blocked by design.
• Approval boundaries should state what the agent may draft, what it may send, and what always needs a person.
• Expand responsibilities in stages, and only after the records have been tested on real jobs.

Why artwork version control comes first

Shops lose time when a customer replies to an old proof, when a separation file is edited after approval, or when the printed art does not match the file in the folder. Version control means every artwork file has a stable identity, a status and a recorded approver. A shop that already runs a good naming habit still needs more than names, because the approval itself must be stored: who approved, through which channel, and against which revision. The print shop agent guide covers the broader setup, but the artwork record is where most errors start.

A workable baseline looks like this:

• Give each design an identity that survives revisions, such as the customer name plus the artwork family.
• Store each revision as its own record with a revision label, a saved copy reference and the date it was created.
• Record the approval: who approved, through which channel, and against which revision.
• Mark exactly one revision as approved for production, and clear that mark the moment a new revision is made.
• Keep superseded files findable but locked, so nobody prints from them by accident.

When these rules hold, a question like "which file do we print from for this reorder" has one answer. When they do not hold, an agent will answer confidently from whichever file it found first, and the error will look like a normal reply.

How to set up screen reuse records

Screens are costly to make and easy to lose track of. A reuse record links a design revision to the screens that carry its separations, along with the frame size, mesh count, emulsion date and storage location. The purpose is practical: someone should be able to answer "do we already have screens for this job" in under a minute, without walking the shelves.

A simple checklist keeps the record useful:

• Record each screen with its mesh count, frame size and the color or separation it carries.
• Link every screen to the artwork revision it was exposed from, not only to the customer name.
• Log reclaim and reuse events, including when a screen was stripped and exposed again.
• Note condition and known defects such as pinholes or ghosting, so a reorder does not quietly reuse a failing screen.
• Record the storage location, even if it is a shelf label, and update it when a screen moves.

The reuse log also protects the shop from a common mismatch. A reorder that uses the same design but a different mesh count or ink system may print differently, and the record should make that visible before the press is set.

Reorder reminders that do not double-run

A reorder reminder is both a prompt for the shop and a promise to the customer. There are two failure modes: a missed reminder and a duplicated one. The second is easy to overlook once a scheduled job, a salesperson and an agent can all see the same reorder date. The fix is to choose one owner for the schedule and to give every reminder a unique key built from the customer, the artwork revision and the reminder date.

Payment platforms handle a similar problem with idempotency keys, so that a retried request does not create a second charge. The same idea applies to a reminder queue. If the key already exists, the system does nothing and logs that the reminder was already handled. [Stripe's documentation on idempotent requests](https://docs.stripe.com/api/idempotent_requests) describes the pattern in detail.

Reminders should also count backward from the customer's need date, not forward from the last print run. Supplier restocks for ink and emulsion belong in the same view, because a reorder that cannot be produced on time is a scheduling failure, not a customer problem. The same logic appears in procurement follow-up with quotes and suppliers, where timing gaps are the usual source of delay.

A decision guide for what the agent may do

Once the records exist, the boundary should be written down before the agent touches a customer. A plain decision guide is easier to review than a long policy:

• If the revision is marked approved and the screens are logged in good condition, the agent may draft the reorder confirmation for a person to review.
• If the revision is unapproved, or the approval predates the current file, the agent may ask the customer to confirm the design but may not state a production date.
• If the screens are missing or flagged as defective, the agent may open a task for the production lead and must not promise a delivery window.
• If the customer asks to change colors, ink system or garment type, the agent routes the request to a person, because the change affects the approval and the quote.
• If a reminder would duplicate one already sent, the agent stops, logs the conflict and leaves the decision to staff.

The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers a useful vocabulary for this work: identify the risks, measure how often the agent gets a case wrong, and govern who can change the boundary. For a print shop, the measurement can be as simple as a weekly list of cases where the agent cited the wrong revision or missed a flagged screen.

Illustrative scenario: a repeat team order

This scenario is illustrative and does not describe a real shop. A print shop produces a two-color design for a local amateur soccer club every season. In spring, the club asks for the same shirt with a new sponsor line at the bottom. Without records, staff search for last year's file, find two versions and reprint from the wrong one. With the records described above, the agent finds the approved revision, notices that the sponsor line is new, and drafts a revision request for a person. The reuse log shows the front screen is in good condition, while the back screen was flagged for ghosting last year, so the production lead is alerted before the press is scheduled. The agent does not confirm a date until the new revision is approved and the back screen is either repaired or replaced.

What Be Human's managed approach covers

Be Human begins with a first engagement that defines one useful role, the memory and tools that role needs, its approval boundaries and an observable success criterion. For a print shop, that often means the agent reads the approved revision and the screen log, drafts reorder messages and routes exceptions to named staff. Managed operations then cover monitoring, such as checking whether replies cite the correct revision, recurring evaluations against a fixed set of past jobs, permission review when staff roles change, and controlled updates when the shop adds a product line. The agent does not send anything to customers outside the boundaries the shop has chosen.

Sequencing the work before expanding responsibilities

The order matters more than the tools. A shop that starts with an agent before its records are clean will spend its time correcting confident mistakes. A sensible sequence looks like this:

• Audit the current artwork files and mark the approved revision for each active customer.
• Build the screen reuse log for the designs that repeat most often, before covering the rest.
• Turn on reorder reminders with one owner, one schedule and a unique key for each reminder.
• Run the records by hand through several real job cycles, and note every wrong answer.
• Only then let the agent draft confirmations, with the decision guide written into its instructions and a short, current set of records in its context. [Anthropic's notes on context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) explain why a smaller, well-maintained context usually beats a large, stale one.

If you want to find the first task in your shop that is worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

What does an AI agent do for a screen printing shop? It reads approved artwork records, checks the screen reuse log, drafts reorder confirmations and routes exceptions to staff. It should not decide production dates, change colors or send anything outside the approval boundaries the shop has defined. Its usefulness depends on the quality of the records it reads.

Do we need to digitize every old screen before using an agent? No. Start with the designs that repeat most often, because they produce the most reorders and the most avoidable confusion. Covering the rest can follow once the first records have been tested on real jobs.

How is an agent's reorder reminder different from a calendar entry? A calendar entry tells a person that something is due. A reminder with a unique key, a single owner and a link to the approved revision can also check whether the reminder was already sent, confirm the artwork is current and flag missing screens before the customer is contacted.

What should stay with a person? Color changes, substrate changes, production dates, any quote change and any decision about a flagged screen should stay with staff. The agent can prepare the case with the revision, the screen status and the open questions, so the person can decide quickly.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.