Applied AI · 4-6 weeks
AI Agents for Commerce Ops
An AI agent is only as good as the data it can reach. We build conversational agents wired directly into your live order, inventory, and fulfillment data, so your team gets a correct answer in seconds instead of opening four systems. Built by the same architects who connect those systems in the first place.
Talk Through a Use CasePipe17 subcontracts us to deliver implementations for their own customers.
How many units of SKU AW-4471 can we promise this week?
1,240 units available to promise.
890 on hand across NJ and NV · 350 inbound, lands Thursday · 210 already allocated to open orders and excluded.
Illustrative example, not customer data
Engagement
4 to 6 weeks
Kickoff to a working agent
Model
Model-agnostic
Not tied to one vendor
You receive
An evaluation set
Check the answers yourself
Wired into
Live data
Orders, inventory, fulfillment
Delivered by
Ex-Pipe17
Solution architects
Our Approach
Why This Comes From an Integration Team
Most failed AI projects in commerce operations fail for the same reason: the agent was built on top of a data layer nobody had validated. It answers confidently, it answers wrong, and the team stops trusting it inside a month.
We spend our working lives inside the systems that hold this data: which orders are real, which inventory numbers can be trusted, where the sync gaps are. We build agents on data we have verified, and we tell you which questions your data cannot reliably answer yet.
What We Build
Inventory & Order Assistant
For Your Operations Team
“How many units of this SKU are available to promise across all warehouses?” “Why hasn’t this order shipped?” Natural-language access to live inventory and order state, without training anyone on NetSuite saved searches.
- Available-to-promise across sites
- Order status without a saved search
- No NetSuite licence required
Customer Support Agent
For Support, Then Customers
Order status, tracking, delivery estimates, and returns eligibility answered from live system data rather than a stale export. Deploy it behind your support desk first, then in front of customers once you trust it.
- Live tracking and delivery dates
- Returns eligibility from real policy
- Internal pilot before public launch
Exception Triage
For Whoever Is On Call
Stuck orders, failed syncs, and fulfillment exceptions summarised in plain language with a probable cause and a suggested action, so triage does not depend on the one person who knows where to look.
- Plain-language failure summaries
- Probable cause, not just an error code
- Removes the single-point-of-knowledge
How We Build It
Four to six weeks. Step one is the one that protects you: if your data cannot answer the question reliably, we say so before you have spent anything on a build.
Week 1
Use Case & Data Readiness
We pick the one repeated question the agent will answer, then verify your data can actually answer it correctly. If it cannot, we stop here and tell you what to fix first.
Weeks 1-2
Data Access Layer
We build the tools the agent is allowed to call (SuiteQL queries, Pipe17 endpoints, 3PL lookups) and decide per field whether it reads live or from cache.
Weeks 2-4
Agent Build & Evaluation Set
Prompts, tools, and guardrails, plus a test set of real questions from your team with verified answers, so “is it working?” has a measurable answer.
Weeks 4-6
Pilot, Tune & Handover
Your team uses it against real work while we watch what it gets wrong and tighten it. Then deployment, monitoring, and documented handover.
Where This Works, and Where It Doesn’t
We would rather lose the project than build an agent on data that cannot support it.
This works when
- Your order and inventory data is already reasonably trustworthy, or you are willing to fix it first
- There is a specific, repeated question your team answers by hand many times a day
- Someone owns the outcome and can tell us what a correct answer looks like
This won’t work, and we’ll say so before you spend anything
- ✕Your underlying data does not reconcile. An agent on bad data produces confident wrong answers faster than a human does. Fix the integration first. That is the audit.
- ✕You want “AI” without a specific job for it to do. We do not sell exploration.
- ✕The real problem is a broken process. An agent will make it faster, not better.
What You Receive
The Deployed Agent
Running in your environment, against your data, in the tool your team already uses.
Full Source
Prompts, tool definitions, and integration code. Same terms as our development work: it is yours, and you are not locked in to us.
A Documented Data-Access Map
Every field the agent can read, and every field it deliberately cannot. You know exactly what it has access to.
An Evaluation Set
Real questions from your team with verified answers. Re-run it after any change and know immediately whether the agent still works.
Guardrail & Escalation Spec
What it refuses to answer, and when it hands off to a human instead of guessing.
Questions We Get Asked
Which model do you use, and where does our data go?
We are model-agnostic by design. The integration layer is the hard part; the model is a component we select to fit your constraints, not a commitment you inherit from us. In practice that means we deploy on whichever provider your security review approves, including inside your own cloud account, so order and customer data never leaves your boundary. Your data is never used to train a model, and nothing in the build depends on fine-tuning one.
Does it read live data, or a copy?
Both, deliberately. Anything where a stale answer is a wrong answer (order status, available-to-promise inventory, shipment tracking) is read live. Slow-changing reference data like SKU masters, warehouse lists, and channel mappings is cached and refreshed on the same integration events we already handle. That split is not a shortcut: querying NetSuite live on every turn burns governance units and hits concurrency limits fast, which is the thing that quietly breaks agent projects built by teams who have not run production NetSuite integrations.
Where does our team actually use it?
Slack or Teams for internal ops and support agents, your team is already there, so adoption needs no training. Customer-facing agents run as an embedded widget, deployed behind your help desk first until you trust it. We can build inside NetSuite as a Suitelet, but we usually advise against it as the first deployment: it limits the agent to people who hold NetSuite licences, and the ops staff who would benefit most often do not have one.
What does it cost to run after you leave?
There is a real ongoing cost and we would rather you hear it now. Model usage is billed to your own provider account. We do not resell tokens or mark them up, and you see exactly what you are spending. At internal ops-team volume that is typically a modest monthly line; a customer-facing agent handling order-status volume costs more and scales with traffic. Hosting is minor. The only optional cost is a retainer to maintain prompts and the evaluation set as your catalog and processes change.
What happens when it gets something wrong?
It is designed to say it does not know rather than guess. The guardrail spec defines which questions it refuses and when it escalates to a person. And because you hold the evaluation set, a wrong answer becomes a test case you can add and re-run, rather than an argument about whether the agent is any good.
See it answer questions about your own data
Four to six weeks from kickoff to a working agent, delivered with an evaluation set so you can check the answers yourself rather than take our word for it.