Catalyst ai

Inspiration

Small ecommerce teams do not operate from one clean system. Orders may live in Shopify, warehouse updates appear in Slack, invoices arrive by email, and operating rules are often stored in spreadsheets, contracts, or someone's memory.

While researching real logistics complaints, I noticed that many costly problems were not caused by a lack of data. The information already existed, but it was scattered across different tools and discovered too late. A priority order might be sitting unfulfilled while the warehouse has already mentioned a stock issue in Slack. A 3PL may charge the wrong rate, but nobody compares the invoice with the active contract until weeks later.

I wanted to build something beyond another dashboard or chatbot. The goal was an adaptive operations system that could gather evidence, identify exceptions, explain its reasoning, recommend an action, and still keep people in control.

What it does

FulfillGuard is an adaptive operations engineer for ecommerce fulfillment teams.

It brings order data, warehouse conversations, and business evidence into one command center. It then:

1. Detects fulfillment, inventory, and billing exceptions.
2. Connects related evidence from multiple systems.
3. Ranks cases by customer and financial impact.
4. Explains why each case was created.
5. Recommends the next operational action.
6. Requires human approval before making an external change.
7. Records evidence, tool calls, decisions, and approvals in an audit log.

For example, FulfillGuard can find a paid priority order that is still unfulfilled, check recent warehouse messages for the cause, create an evidence-backed risk case, and draft a Slack escalation. The message is only sent after a person approves it.

The project also includes a maintainer agent. When business behavior changes, it detects policy drift, proposes a versioned workflow update, tests that update against historical cases, and requests approval before deployment.

How I built it

I built FulfillGuard with Next.js, React, TypeScript, and backend API routes.

The Shopify and Slack tool chain can use real credentials when configured. It queries unfulfilled orders, reads relevant warehouse messages, correlates the evidence, and produces a governed recommendation. For judges, the same workflow works without external accounts through deterministic demo data, so the complete experience can be tested immediately.

The system separates the workflow into specialist responsibilities:

• A discovery agent understands the operational requirement.
• An integration agent selects the required systems and tools.
• A workflow agent creates the decision process and approval boundaries.
• A validation agent checks the workflow before deployment.
• A maintainer agent monitors policy drift after deployment.

Codex was my implementation partner throughout the build. I used it to develop and debug the product interface, backend routes, Shopify and Slack tools, deterministic fallback behavior, tests, documentation, and Remotion demo video.

GPT-5.6 Terra helped me reason through the multi-agent decomposition, evidence model, workflow safety, approval boundaries, policy-drift process, and the clearest way to demonstrate the product. I made the final decisions about the problem, scope, user experience, and safety constraints.

Challenges I faced

The largest challenge was making the project genuinely agentic without turning it into an uncontrolled automation system. An agent that can read business systems and send messages is useful, but it can also make expensive mistakes. I therefore separated evidence gathering, reasoning, drafting, approval, and execution into visible stages.

Another challenge was demonstrating real connector behavior without requiring judges to create Shopify and Slack accounts. I solved this by building deterministic fallbacks behind the same backend orchestration path. Live credentials enable real calls, while judge mode produces a repeatable and safe tool trace.

I also had to reduce a broad vision into a focused proof of concept that could be built and explained clearly during Build Week. I chose fulfillment risk as the primary workflow while still showing how the architecture could support billing disputes, inventory mismatches, and other operational exceptions.

What I learned

I learned that useful business agents need more than a good prompt. They need narrow responsibilities, structured tool contracts, evidence provenance, observable state, tests, approval boundaries, and failure handling.

I also learned that adaptive automation should not silently rewrite itself. A safer approach is to treat workflow changes like software changes: generate a versioned proposal, show the difference, test it against historical cases, and ask a person to approve deployment.

Most importantly, I learned that the value is not simply connecting more applications. The value comes from turning scattered information into a timely, explainable, and governed decision.

What's next

The next step is to pilot FulfillGuard with a real ecommerce merchant or 3PL and measure missed-SLA prevention, investigation time, false alerts, and recovered costs.

I would then add OAuth-based Gmail and ERP connectors, durable workflow storage, role-based access, background processing, evaluation datasets, and configurable approval policies. Over time, FulfillGuard could become a reusable operations layer where a business describes its process in plain language and receives a maintained, testable, and auditable operational application.

Built With

• antigravity
• codex