Two AI surfaces on one commerce platform, metered separately

Overview

Atlantis Print sells print-on-demand products with deep variant structures — sizes, materials, finishes, quantities — where pricing depends on the combination. That complexity is exactly what makes ordering hard for customers and quoting slow for staff.

We built two AI surfaces on the platform that look superficially similar and are engineered quite differently, because they carry different risks and different costs.

---

Key challenges and solutions

Challenge 1: A public agent with write access to commerce

A customer-facing agent that can add to a cart and place an order is a genuinely dangerous piece of software if built carelessly. It is exposed to the open internet and it touches money.

Our solution: every capability is an explicit typed tool — setting fulfilment, capturing a lead, submitting a quote request, querying live catalogue pricing, managing the cart, placing the order. Pricing comes from the live catalogue at call time rather than from anything the model believes it remembers. Chat sessions link to customer records so a conversation that starts anonymously can be attached to an account without re-asking for everything.

Challenge 2: Internal and external AI have opposite cost profiles

Staff use AI heavily and unpredictably. Customers use it in short bursts, and their usage is a cost of sale. Treating both as one feature would have meant either throttling the team or leaving spend uncapped.

Our solution: two separate routes. The internal organisation assistant is credit-metered with a user-selectable model allowlist defined in billing configuration, so which models a tier may use is a commercial decision rather than a code change. The public path is deliberately not metered the same way. Keeping them apart meant each could be tuned for its own economics.

Challenge 3: A missing environment variable should not take down AI

Model identifiers configured by environment variable are a common and quiet source of production failure — a typo or an unset variable resolves to undefined and every call fails.

Our solution: model configuration is centralised in one module with an environment override and a hard-coded fallback, so the resolved model is never undefined regardless of deployment state.

Challenge 4: No way to know whether any of it was working

The platform also generates AI comment summaries, drafts customer emails, and classifies bespoke quote requests. Across that many surfaces, "it seems fine" stops being a usable standard.

Our solution: a privacy-safe evaluation pipeline. Production transcripts are exported org-scoped and redacted of personal data, with fixtures kept out of version control, then used for open-coded error analysis. The failure modes found this way are written into a shared taxonomy, so the team has an actual vocabulary for how the system goes wrong rather than a folder of screenshots.

---

What we did

• Public ordering agent
• Credit-metered internal assistant
• Evaluation pipeline
• Stripe & Square payments
• tRPC & Drizzle
• Next.js & PostgreSQL

---

What shipped

2

Separately metered AI surfaces

Per-tier

Model allowlists as a billing surface

PII-safe

Redacted production transcript export

Written

Failure taxonomy for error analysis

---

Conclusion

The lesson worth taking from this project is that "add AI to the product" is not one decision. A customer-facing agent and an internal assistant have different threat models, different cost profiles, and different acceptable failure rates — and building them as one system would have compromised both.

---