How to add AI agents to Fishbowl
Short answer
Put a thin tool layer between the agent and Fishbowl: read-only SQL or report queries for analysis, and the Fishbowl REST API (or the legacy API) for writes that a person approves. Start with one narrow agent such as a reorder reviewer, measure it against what your buyers actually do, then widen.
Most Fishbowl shops are small to mid-size manufacturers and distributors running Fishbowl Advanced on a server in the back office, often with QuickBooks beside it. The people who run it are stretched: one buyer, one planner, a warehouse lead. The work that eats their week is repetitive judgment: which parts are short, which POs are late, which sales orders will not ship because one component is missing.
An AI agent is useful here when it does that judgment first and hands a person a short, checked list. It is not useful as a free-roaming bot that edits inventory. Fishbowl has no built-in agent framework, so the pattern is an external service that reads Fishbowl data, reasons over it, and proposes actions.
The good news is that Fishbowl exposes enough surface for this: a MySQL database you can read, a REST API with token auth, and CSV import and export. The constraint is that many installs are on-prem, on older versions, and nobody wants a cloud tool with write access to the inventory ledger.
What teams use it for
Reorder review
Each morning the agent compares on-hand, committed, on-order and reorder points per part, then drafts a short list of purchase orders with quantities and preferred vendors for the buyer to approve.
Short-part triage for work orders
For released manufacture orders, the agent walks the bill of materials, finds components that are not available, and tells the planner which orders will slip and which substitute parts exist.
Late PO chasing
The agent finds open PO items past their expected date, groups them by vendor, and drafts a single follow-up email per vendor with the part numbers and original promise dates.
Cycle count prioritization
It looks at inventory adjustments and negative or odd quantities by location and proposes which bins to count first.
Sales order shipping blockers
It explains in plain language why a sales order cannot be picked or shipped: unpaid hold, missing stock, wrong location, or an unfulfilled kit component.
Costing anomaly watch
It flags parts whose last received cost jumped sharply against the average cost, a common source of bad margins after vendor price changes.
Fishbowl integration surface
- Fishbowl REST API: token login with an integrated app that an admin approves inside Fishbowl, then JSON endpoints for parts, purchase orders, sales orders and more. Exact endpoint coverage differs by version, so check your server's API documentation.
- Legacy Fishbowl API: a JSON-over-TCP interface to the Fishbowl server that older integrations use for requests such as import, queries and saving orders. Still found on many on-prem installs.
- MySQL database: Fishbowl Advanced stores data in MySQL. A read-only database user is the simplest way to give an analysis agent fast access to part, inventory and order tables. Table and column names such as PART, PO, POITEM, SO, SOITEM and WO are common but verify against your version.
- Import and export: CSV import and export for parts, orders and inventory, handy for batch writes that should go through Fishbowl's own validation.
- Reports: Fishbowl reports are built on a Jasper-based reporting engine and can be run and exported, which gives the agent a vetted query path without touching tables.
How it works
- 1
Pick one narrow job
Choose a task with a clear right answer a human already produces, such as the weekly reorder list. Capture last quarter's manual outputs as your test set.
- 2
Give the agent read access first
Create a read-only MySQL user, ideally on a replica or a nightly copy so heavy queries never slow the live server. Expose a handful of named query tools, not raw SQL, at first.
- 3
Define tools with strict schemas
Examples: get_part_availability(part), list_open_po_items(vendor, days_late), get_bom(part). Each returns small JSON. The model chooses tools, your code runs them.
- 4
Run an open-weight or approved model
Serve a model on a local GPU box with vLLM or Ollama, or use a cloud model if policy allows. The model never sees credentials.
- 5
Add proposals, not writes
The agent produces a proposed PO or work order as structured data and a reason. A reviewer sees it in a simple page or email.
- 6
Write through the API after approval
On approval, a separate service account calls the Fishbowl REST API to create the draft order in an unissued state. Log who approved what.
- 7
Evaluate and widen
Compare agent proposals to buyer decisions for a month. Only add the next agent when acceptance is stable.
Example flows
Morning reorder review
Trigger: Scheduled at 6:00 each weekday.
- Agent queries parts below reorder point with committed demand over the lead time.
- It checks open POs so it does not double-order.
- It picks the preferred vendor and last cost for each part.
- It drafts grouped PO proposals with reasons.
- Buyer approves, edits or rejects in a review page.
Result: The buyer reviews ten proposals in minutes instead of building them from a stock report.
Work order shortage alert
Trigger: A manufacture order is released in Fishbowl.
- Agent reads the order and expands the BOM.
- It checks availability by location and any open POs due before the start date.
- It notes shortages and possible substitutes from the part record.
- It posts a summary to the planner.
Result: The planner learns about the missing component before the floor does.
Vendor delay digest
Trigger: Weekly on Monday.
- Agent lists PO items past their expected date.
- It groups them by vendor and attaches original promise dates.
- It drafts one email per vendor for a buyer to send.
Result: Late orders get chased consistently without the buyer compiling lists.
Keeping data on-prem
Fishbowl is commonly installed on a customer server, so the whole agent stack can stay inside the network. Put the agent service on the same LAN, give it a read-only MySQL replica and an API account scoped to draft orders, and serve the model from a local GPU machine using vLLM or Ollama. Nothing about part costs, vendors or customer orders leaves the building. If you run Fishbowl in a hosted environment instead, confirm with your host what database and API access is allowed, because direct MySQL access is often closed there and the REST API becomes the only path.
Security checklist
- Use a read-only database user for analysis and a separate, narrowly scoped API account for writes.
- Never let the model compose raw SQL against the live database; expose named query tools with parameter validation.
- Create orders only in a draft or unissued state and require named human approval before issue.
- Keep an audit table of every tool call, proposal and approval with the user and timestamp.
- Redact vendor pricing from prompts when using any external model.
Ways to get it done
Fishbowl's own reports and automation features
Effort: Hours to days, no code.
Enough when you only need threshold alerts or scheduled reports with no reasoning.
Build in-house with the REST API and a read replica
Effort: Typically a few weeks for one agent with evaluation.
Good if you have a developer comfortable with Python or Node and a clear first job.
Work with a partner such as Netray
Effort: Scoped pilot first, then extend agent by agent.
Fits when data must stay on-prem, you want open-weight models, and you need approval workflow and audit built correctly.
Pitfalls
- !Letting the agent read the live database during business hours with expensive queries that slow down receiving and picking.
- !Ignoring unit of measure conversions, so reorder quantities come out in the wrong unit.
- !Double-ordering because the agent did not account for open PO quantities and in-transit stock.
- !Starting with write access. Build trust with read-only proposals first.
- !Assuming API fields are identical across versions; test against your exact server.
Frequently asked questions
Can an AI agent create purchase orders in Fishbowl on its own?
Technically yes through the API, but you should not allow it at first. Have the agent create proposals, let a buyer approve, and only then write a draft PO. Issuing and receiving should stay human steps until you have weeks of evidence that proposals are reliable.
Do I need the Fishbowl REST API for this?
Not for reading. A read-only MySQL user or exported reports can feed an analysis agent. You need the REST API or the legacy API only when the agent's approved output must write back, and then the API keeps Fishbowl's own validation in the loop.
Will this work on an older Fishbowl version?
Often, yes, because the database and legacy API have been stable for years. The REST API is newer and may not exist on very old builds. Check your version's documentation and test table names before designing tools.
Does the model need to be in the cloud?
No. A modest open-weight model on a local GPU can handle tool-calling for inventory tasks. Cloud models are fine if your policy allows sending part and vendor data, but many manufacturers prefer to keep it local.
How is this different from Fishbowl reports?
Reports show data you already asked for. An agent decides what to look at, combines stock, BOMs and open orders, explains the answer, and drafts the next action for approval. If you only need a fixed report, a report is simpler and cheaper.
Want AI agents working on your Fishbowl?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment