Many Minions

Inspiration

Commerce teams run on several platforms at once. Shopify holds the store, Bloomreach the catalog and campaigns, Databricks the numbers. Each one takes specialist knowledge: which API to use, what it needs, what should happen next. Knowing one doesn't help you with the others. The tasks themselves are small ("how many products are low on stock?", "create a 15% code that starts in an hour", "send me last week's orders as a CSV every Monday"). Each still needs someone who knows that tool, and that person rarely has time. We wanted a person to just ask, and have the details taken care of on the team's own connected accounts.

What it does

Many Minions takes a commerce request, either a question or an instruction, and carries it out across the accounts a workspace has connected: Shopify, Bloomreach and Databricks. A request can run once, on a schedule, or when a monitored condition holds (for example, "tell me when a new paid order comes in").

• Gemini reads the request and can draft text. The application, not the model, owns planning, permissions, approvals and the record of the work.
• The minions find what the request names, choose from declared capabilities, ask about anything they can't resolve, and return an answer, completed work or a file.
• Writes stop for approval unless a standing approval covers that change within its limits. A separate read-back identity then checks that the change actually happened.
• The team learns. An object graph remembers where products, orders and campaigns live and how they link across vendors. A procedure that is verified in two separate runs becomes a kept route that later requests can reuse, as long as the provider surface and the caller's permissions still match.
• Two surfaces, one record. The web workspace is for starting and reviewing work, inspecting evidence, browsing Knowledge, and managing schedules, monitors and approval rules. The Mac notch client lets you start work from the desktop and follow it live (Thinking → Working → Asking → Done), and answer questions or approvals from there too.

How we built it

• Next.js + React + TypeScript on Node.js 24, with PostgreSQL for the workspace, the event journal and the object graph.
• Gemini (via the Google Gen AI SDK) interprets requests. A bounded, read-only ADK explorer proposes routes for parts no declared capability covers. It can propose, but it can never authorize a write.
• The planner searches declared capability states. Each capability requires some facts and produces others at a declared cost, and a plan is one reachable chain of those states.
• Vendor adapters check every write before it is sent: Shopify Admin API (REST and checked GraphQL drafts), Bloomreach partial catalog updates and reads through Loomi, and Databricks MERGE and read-only SQL on declared tables.
• An event journal is the record of each run. Recovery replays it, staged routes keep a durable cursor, and an effect with an unknown outcome follows its declared recovery instead of being resent on a guess.
• Better Auth for sign-in, an MCP interface to the knowledge graph, a Swift notch app for macOS, and Docker packaging for Cloud Run, with Cloud Scheduler triggering schedules and Secret Manager holding credentials.
• A Vitest suite with vendor doubles, plus ESLint, a type check, migration checks and Docker builds in CI.

Challenges we ran into

❯

• Memory that doesn't go stale. The graph stores identities and locations, never prices, message bodies or credentials. Current values are always fetched fresh.

Accomplishments that we're proud of

• Real cross-vendor runs against live Shopify, Bloomreach and Databricks accounts, not mocks.
• "Not a chatbot, not another dashboard": the permissions, the read-back check and the team memory are ours, not a wrapper around a model.
• A desktop notch that makes a background agent feel present without getting in the way.

What we learned

• Agents get useful when the model's job is kept narrow. Reading intent is a good fit for an LLM. Deciding what's allowed is not.
• Reuse has to be earned. Routes are kept only after two verified runs, and we measured savings for some Bloomreach queries but not for every route, so we don't claim a universal speed-up.

Built With

• better-auth
• bloomreach
• bloomreach-loomi
• databricks
• docker
• google-adk
• google-cloud-run
• google-cloud-scheduler
• google-gemini
• google-gen-ai-sdk
• google-secret-manager
• graphql
• macos
• mcp
• next.js
• node.js
• playwright
• postgresql
• react
• shopify-admin-api
• sql
• swift
• typescript
• vitest