2 ready-to-build workflows

AI agent workflows for Printing & packaging

Turn quote requests and proof chasing into grounded, gated workflows — with every price commitment and proof sign-off human-approved.

Each recipe below is expressed only in VegaDūta's real workflow building blocks — Trigger, Agent, Knowledge, Condition, Approval, Output, Tool (MCP), Voice, Device, Loop, Code and Parallel — so it maps 1:1 to something you can assemble in the Workflow designer. Consequential actions always pass a human Approval step.

1. Quote request → grounded estimate, price approved before it goes out

Estimate requests land by email, WhatsApp and web form with half the spec missing. The estimator re-reads the rate card, chases the customer for the missing details, prices it by hand, and quotes drift out days later.

Trigger: Email / WhatsApp / Webhook (quote request)

How the workflow runs

Trigger
Quote request arrives. An Email, WhatsApp or Webhook (web form) trigger catches the request.
Agent
Parse the job spec. An Agent node extracts the printable spec — product, stock/GSM, size, quantity, colours, finish, turnaround — into structured fields.
Condition
Spec complete?. A Condition node checks the mandatory fields; an incomplete spec branches to a single, specific clarification message instead of a wrong price.
Knowledge
Price from the rate card. A Knowledge node grounds the estimate in your current rate card / material pricing — the agent computes the estimate only from documented rates, never a made-up number.
Approval
Estimator signs off the price. An Approval node holds the estimate — a price to a customer is a binding commitment, so a human confirms (or edits) before it is ever sent.
Output
Send the quote. An Output node sends the approved estimate on the customer's channel, itemised, with validity and next step.

Channels & connectors

Email
WhatsApp
Webhook
Knowledge base
Approval / HITL
Tool (MCP → print MIS)

Outcome

Requests become itemised, rate-card-grounded estimates within the hour, and no price reaches a customer without an estimator's sign-off.

Why it helps

Removes the re-keying and back-and-forth while keeping the commitment human — the agent assembles a complete, grounded estimate; the estimator just approves or adjusts.

Build spec

1 agent — 1 estimating agent; the completeness gate, the price approval and the MIS lookup are workflow nodes.

System prompt (paste-ready)

You are a print estimator's assistant for {{press}}. From a quote request, extract the spec {product, stock, gsm, size, quantity, colours (e.g. 4/0, 4/4), finish[], turnaround}. If any mandatory field is missing, do NOT price — return {complete: false, missing[]} so the workflow asks one clear clarification. When the spec is complete, compute an itemised estimate USING ONLY the rate card in Knowledge {line_items[{desc, unit, rate, amount}], subtotal, tax, total, validity}. Never invent a rate, discount, or lead time not in the rate card. This is a draft for an estimator to approve — never present it as a confirmed price.

MCP connectors

Print MIS / print-ERP (job + customer history) — via a Tool (MCP) node (no first-party connector)
Email / WhatsApp — request + quote channel
Web form — inbound via Webhook

Built-in tools

knowledge_search (current rate card / material pricing)
http_request (pull customer / prior-job pricing from the MIS)

Guardrails

Every price is a draft until the estimator approves at the Approval node — no quote leaves without a human sign-off
Estimates are computed only from the rate card in Knowledge — no invented rates, discounts or lead times
An incomplete spec forces a single clarification (completeness gate) instead of a guessed price

Cost strategy

One standard-tier agent per request handles parsing and rate-card pricing in a single pass; there is no batch multiplier. If request volume grows, drop the completeness-check pass to an economy-tier model and reserve the standard tier for the priced estimate — the clarification path never needs the bigger model.

Output & delivery

The agent parses the spec → the Condition node gates completeness (clarifying if needed) → it prices from the rate card in Knowledge → the estimator approves or edits at the Approval node → an Output node sends the itemised quote with validity on the customer's channel, and the draft is linked to the MIS job.

2. Proof approval collection with a completeness gate

A job can't go to plate until the customer signs off the proof — but sign-offs come back partial ('page 2 looks fine') or never, and someone has to chase each one and confirm every element was actually approved before releasing to print.

Trigger: Webhook (proof ready from prepress) / Email

How the workflow runs

Trigger
Proof is ready. A Webhook from prepress (or an Email) fires when the proof PDF is ready, with the job and its list of proof elements (pages, dielines, spot colours).
Agent
Compose the sign-off request. An Agent node builds a clear approval request with an explicit checklist of every element that must be signed off, and sends the proof link.
Output
Send + collect the sign-off. An Output node delivers the proof and checklist on WhatsApp or Email and collects the customer's responses.
Condition
Completeness gate. A Condition node checks that EVERY listed element is explicitly approved — a partial or ambiguous reply is not treated as a full sign-off; it loops back for the outstanding items.
Approval
Release to print. An Approval node holds the release-to-plate decision — a proof sign-off is binding, so production confirms full customer approval before the job advances.
Tool (MCP)
Mark approved-to-print. On release, a Tool (MCP) node sets the job to approved-to-print in the MIS and attaches the sign-off record.

Channels & connectors

Webhook
Email
WhatsApp
Approval / HITL
Tool (MCP → print MIS)

Outcome

Every proof element is explicitly signed off before a job goes to plate, and the release is a human decision with the approval trail attached.

Why it helps

Replaces manual chasing and the risk of plating on a partial 'looks fine' — the completeness gate makes 'fully approved' a checked fact, not an assumption.

Build spec

1 agent — 1 proof-coordination agent; the completeness gate, the release approval and the MIS write are workflow nodes.

System prompt (paste-ready)

You are a prepress proof coordinator for {{press}}. Given a job {job_id, proof_url, elements[]} (each element is a page/dieline/spot colour that needs sign-off), compose a clear approval request that lists EVERY element and asks the customer to approve each one. As replies come in, map them to the checklist and return {approved[], outstanding[], ambiguous[]}. Treat only an explicit approval as approved — a comment like 'looks fine' on one page does NOT approve the others. Never mark the proof fully signed off yourself; report the checklist state so the workflow's gate and the human release decide.

MCP connectors

Print MIS / job-tracking — via a Tool (MCP) node (no first-party connector)
Prepress output — inbound via Webhook
WhatsApp / Email — proof + sign-off channel

Built-in tools

knowledge_search (per-job element checklist / proofing SOP)
http_request (set job status in the MIS)

Guardrails

The job advances to plate only on the Approval node — the agent tracks the checklist but never releases to print itself
Completeness gate: every listed element must be explicitly approved; a partial or ambiguous reply is not a full sign-off and loops back for the outstanding items
The MIS status write is keyed to the job id and stamped with the sign-off record — auditable and never double-released

Cost strategy

A single standard-tier agent coordinates one job's proof cycle across however many reply rounds it takes; there is no per-item batch. Because the work is short, structured checklist bookkeeping, an economy-tier model is enough for the reply-mapping turns — reserve any heavier tier for jobs with large element lists.

Output & delivery

The agent sends the proof with an explicit element checklist → an Output node collects replies → the Condition node's completeness gate loops until every element is approved → production releases at the Approval node → a Tool (MCP) node marks the job approved-to-print in the MIS with the sign-off record attached.

Related industries

AI agent workflows for Warehousing & 3PL fulfilment

Build one of these in minutes

The sandbox gives you a live agent workspace — no account, no card. Or head back to the full catalogue and compare patterns across every industry.

Try this in the sandbox — no signup Browse all industries

See how VegaDūta compares to n8n, Dify and BotpressWhy VegaDūta's architectureEstimate your WhatsApp API costs