RedTag

RedTag is an autonomous AI agent fleet that detects product risks, traces affected inventory and customers, executes recalls, recovers from failures, and verifies every action with auditable proof.

Comment

Inspiration

Product recalls are one of those problems where identifying the issue is only the beginning.

Once a defective component is discovered, a company has to answer a much harder set of questions:

Which manufacturing batches used that component? Which finished products contain it? Where are those products now? Which shipments must be stopped? Which customers need to be contacted? Were the notifications delivered? Were the affected products actually returned? And can the company prove that every required action was completed?

Today, much of this work is fragmented across ERP systems, spreadsheets, warehouse software, supplier records, customer databases, email, logistics platforms, and compliance teams.

AI can already summarize a defect report or answer questions about manufacturing data. But we wanted to explore a more ambitious question:

What if AI did not just explain how to manage a recall, but actually coordinated the recall from detection to verified closure?

That question became RedTag.

RedTag is an autonomous multi-agent product recall command center designed around a simple principle:

No action without evidence. No completion without proof.

Instead of creating another assistant that waits for prompts, we designed RedTag as an agentic system that can observe an incident, investigate its impact, coordinate specialized agents, interact with enterprise systems, recover from failures, and continue working until the recall reaches a verifiable outcome.

What it does

RedTag turns a product safety incident into an autonomous operational workflow.

A recall can begin with almost anything:

  • A photograph of a damaged product
  • A supplier PDF
  • A quality-control report
  • A customer complaint
  • A spreadsheet containing batch information
  • A warehouse alert
  • An email from a supplier

Gemini analyzes these multimodal inputs and extracts the relevant component, supplier, batch identifiers, products, severity, and supporting evidence.

From there, RedTag creates an incident and activates a fleet of specialized agents.

Incident Agent

The Incident Agent understands the original safety signal.

It combines information from images, documents, structured data, and incident notes to determine what may have failed and whether additional investigation is required.

Trace Agent

The Trace Agent follows the defective component through the supply chain.

It builds relationships such as:

Supplier component → supplier batch → manufacturing batch → finished product → warehouse → retailer → customer

This allows RedTag to identify the potential blast radius of the incident rather than treating every product as equally affected.

Risk Agent

The Risk Agent evaluates possible recall strategies.

For example, it can compare:

  • Recalling one manufacturing batch
  • Recalling multiple related batches
  • Recalling an entire product family

The agent evaluates estimated customer exposure, operational impact, confidence, and the risk of missing affected products.

Containment Agent

Once an approved recall scope exists, the Containment Agent begins taking reversible operational actions.

It can:

  • Quarantine affected warehouse inventory
  • Place pending shipments on hold
  • Flag affected SKUs
  • Prevent recalled inventory from being allocated to new orders
  • Create tasks for locations requiring manual intervention

The important difference is that RedTag does not stop at generating recommendations.

It changes operational state.

Customer Agent

The Customer Agent identifies affected customers and coordinates notifications.

It records whether each notification succeeds and handles delivery failures.

If an email cannot be delivered, the agent can search for an approved alternative contact method, retry through another channel, or escalate the unresolved customer for human review.

Logistics Agent

The Logistics Agent coordinates product recovery.

It can create return workflows, track returned items, associate recovered products with recall cases, and identify locations where affected products remain outstanding.

Supplier Agent

The Supplier Agent coordinates supplier-side investigation and collects supporting documentation while keeping supplier communication isolated from sensitive customer data.

Compliance Agent

The Compliance Agent maintains an audit trail containing the evidence, decisions, actions, timestamps, approvals, and system changes associated with the recall.

Verification Agent

The Verification Agent is intentionally separated from the agents performing the work.

Its responsibility is to verify whether actions actually occurred.

An agent cannot simply claim:

12,431 customers notified

The Verification Agent checks the underlying action records and determines how many were successfully delivered, how many failed, how many were retried, and how many remain unresolved.

This creates what we call the Recall Proof Graph.

The Recall Proof Graph represents the recall as a chain of evidence:

Defect detected → batches traced → inventory quarantined → shipments stopped → customers contacted → failures recovered → products returned → unresolved cases escalated → recall verified

RedTag therefore has a clear difference between an AI-generated statement and a verified operational fact.

How we built it

RedTag is designed as a multi-agent system rather than one large agent with unrestricted access to every tool.

We used Gemini as the primary reasoning and multimodal intelligence layer and Google Agent Development Kit (ADK) to structure the agent workflows.

Each agent has a specific responsibility, its own tool permissions, and access only to the information required for its task.

The high-level workflow is:

Incident signal

↓

Incident Agent

↓

Recall Director

↓

Trace + Risk + Containment Agents

↓

Customer + Logistics + Supplier + Compliance Agents

↓

Verification Agent

↓

Recall Proof Graph

The Recall Director coordinates the process but does not perform every action itself. Specialized agents execute individual responsibilities and return structured results.

We used Google Cloud services to provide persistent execution and operational state.

Our architecture includes:

  • Gemini for reasoning and multimodal understanding
  • Google ADK for agent orchestration
  • Cloud Run for scalable backend services
  • Firestore for incident state and agent workflow data
  • Pub/Sub for asynchronous events between long-running processes
  • Cloud Storage for incident evidence such as PDFs, images, and reports
  • BigQuery for analysis of larger operational and recall datasets
  • Secret Manager for credentials and protected configuration
  • Model Armor for additional protection around unsafe or malicious model inputs
  • Google Cloud observability tools for logs, traces, errors, and agent execution monitoring

We also created simulated enterprise systems for inventory, customers, orders, suppliers, and logistics so the demo can show agents performing real state-changing actions rather than displaying pre-generated responses.

For example, before a containment action the inventory system may contain:

K100 | 412 units | AVAILABLE

After the Containment Agent executes:

K100 | 412 units | QUARANTINED

The action is recorded with the agent responsible, reason, incident identifier, timestamp, previous value, new value, and supporting evidence.

This allows every important decision to be traced back to its origin.

Challenges we ran into

One of the biggest challenges was preventing RedTag from becoming a collection of agents that simply send messages to one another.

A multi-agent architecture is only useful when agents have meaningful separation of responsibilities.

We therefore designed agents around operational boundaries, not artificial personalities.

The Containment Agent can modify inventory state but does not control customer data. The Customer Agent can communicate with affected users but cannot change manufacturing records. The Verification Agent can inspect evidence but cannot silently rewrite the actions it is supposed to verify.

Another challenge was handling partial failure.

Real operational workflows are rarely perfect. Notifications fail. Data can be missing. External systems may become unavailable. A warehouse may not respond.

RedTag therefore treats failure as part of the workflow rather than as the end of the workflow.

An unsuccessful action can produce another task:

Email failed

↓

Find approved alternate contact

↓

Retry

↓

Verify delivery

↓

Escalate if still unresolved

We also had to think carefully about prompt injection and untrusted documents.

A supplier email or uploaded document is evidence, not authority.

For example, a malicious document might contain an instruction asking the agent to ignore policy and export customer information.

RedTag treats content originating from documents and external parties as untrusted input. Sensitive actions are checked against policy before execution.

This became an important part of our architecture because autonomous agents require stronger boundaries than conversational assistants.

Accomplishments that we're proud of

The part of RedTag we are most proud of is that the system is built around completion rather than conversation.

A user does not need to repeatedly ask:

"What should happen next?"

The agents determine the next actions from the current incident state.

We are also proud of the Recall Proof Graph.

It provides a visual and machine-readable representation of what has actually happened during the incident.

Instead of displaying:

Recall complete

RedTag can show:

  • 12,431 affected customers identified
  • 12,308 successfully contacted
  • 123 initial delivery failures
  • 94 recovered through an alternative contact method
  • 29 escalated for manual intervention
  • 100% of affected inventory locations accounted for
  • Outstanding recovery actions clearly identified

This makes agent activity observable and auditable.

Another accomplishment is the system's ability to recover from operational exceptions rather than simply reporting them.

Finally, we designed security boundaries into the agent fleet from the beginning instead of treating security as something to add after the autonomous workflow was complete.

What we learned

The biggest lesson from building RedTag is that an agentic system should not be measured by how intelligently it talks.

It should be measured by what it can safely complete.

We found that reliable agent systems need several capabilities working together:

Reasoning to determine what should happen.

Tools to make something happen.

State to remember what has happened.

Events to continue workflows asynchronously.

Identity and permissions to limit what each agent can do.

Recovery to handle unsuccessful actions.

Observability to understand what agents are doing.

Verification to distinguish an AI claim from an operational fact.

This changed how we think about AI agents.

The hardest part is not giving the model more tools.

The harder problem is determining when an agent should act, what it should be allowed to change, how it should recover when something fails, and how another system can prove that the action really happened.

What's next for RedTag

RedTag begins with product recalls, but the architecture can support a broader category of enterprise incident response.

The same pattern could eventually coordinate:

  • Food contamination recalls
  • Medical device recalls
  • Automotive component recalls
  • Battery safety incidents
  • Supplier quality failures
  • Pharmaceutical batch withdrawals
  • Manufacturing quality escapes
  • Retail product safety incidents

Our next step is to expand RedTag's counterfactual simulation capability.

Before executing a high-impact action, RedTag could evaluate several possible containment strategies and estimate the consequences of each.

For example:

Recall Batch A

Customer exposure: 4,281 Estimated safety coverage: 72%

Recall Batches A + B

Customer exposure: 12,431 Estimated safety coverage: 99.2%

Recall entire product family

Customer exposure: 38,120 Estimated safety coverage: 99.9%

The system could recommend the most appropriate strategy while requiring human authorization for actions above configurable risk thresholds.

We also want to add richer connectors for ERP, CRM, warehouse, commerce, logistics, support, and supplier-management platforms.

Our long-term vision is bigger than automating recalls.

We want RedTag to demonstrate a model for trustworthy enterprise autonomy where AI can:

Observe → Reason → Simulate → Act → Recover → Verify

Most AI systems tell an organization what it should do next.

RedTag is designed to do the work, prove what happened, and keep going until the incident is closed.

Built With

Share this project:

Updates

Submission history