Junction shipped a complete ask-to-order path. This page collects future work: product gaps, production hardening, and ideas from the brief we deliberately left for later.
Live today: aimoassist.com · proof 30/30 · 29/29 · 52/52.
| Item | Why |
|---|
| PostgreSQL | Replace per-machine SQLite for catalog, order book, audit, and kitchen knowledge |
| Vector database | Better product, dish, and recipe search; agent memory embeddings |
| Diet safety | Vectors assist match only; allergen and diet rules still load in full every run |
| Multi-tenant hosting | One managed engine for kitchens that do not run their own |
2. Seeing and improving quality
| Item | Why |
|---|
| OpenTelemetry everywhere | Website, Telegram, engine steps, gateway, open connector |
| Langfuse (or similar) | Prompt and decision cost, latency, quality loops |
| Eval datasets in CI | Keep order and attack suites green on every policy change |
| Operator dashboards | Shared ids from audit sentences to spans |
Watching never becomes approving. Numbers and rules stay in code.
3. Trust and production keys
| Item | Why |
|---|
| KMS for gateway and agent keys | No long-lived PEMs on disk |
| Credential wallet / passkeys | Issue slips and approvals like real credentials |
| Confirm credit and minimum order | Retire written demo assumptions against live accounts |
| Delivery calendars and cut-offs | Match real webshop rules (amend until cut-off) |
| Unit conversion gaps | Where schedule lines use a different sales unit than the catalog |
4. Deeper Valio systems
| Item | Why |
|---|
| Real order intake behind the gateway | Keep today’s order book until an API exists |
| Live credit and payment modes | Invoice vs pay-now from sales terms |
| Richer recipe import | Beyond the cached public set |
| Controlled demo switches | /demo stock overrides only in demo mode |
5. Product and channels
| Item | Why |
|---|
| Valio selling agent (MCP) | Push signed seasonal offers into kitchens; human still accepts |
| Stronger carbon UX | Category-fair comparisons as a product feature |
| Production Telegram | Multi-tenant kitchens, approval cards, voice and photo at scale |
| More kitchen-side helpers | Inventory, claims: still buy only through the same Valio door |
| Native mobile beyond Telegram | Optional; Telegram remains the thin floor channel |
6. Learning and risk (with real outcomes)
| Item | Why |
|---|
| Opt-in learning across kitchens | Aggregated prefs, privacy-preserving |
| Trained delivery-risk / shortage model | Once real delivery outcomes exist (today: transparent on-time scores) |
| Portion proposals in the UI | Accept dish rewrites after the eval gate |
| Standing-approval drafts | Manager signs; agent never signs the slip |
7. Open connector and agents
| Item | Why |
|---|
| Harden MCP for third parties | Docs, SDKs, rate limits, clearer errors |
| Agent wallet as a product | LLMs never hold private keys |
| Second-agent demos as a template | Any outside buyer using the same door |
| Tool-use traces | Tune which connector calls fire, without weakening guardrails |
8. Site and operations
| Item | Why |
|---|
| Harden aimoassist.com | Production URLs, TLS, backups, on-call |
| Managed secrets and config | No .env on laptops for pilots |
| CI on every gateway/policy PR | Rogue + scripted orders as required checks |
| Load and soak tests | Catalog search and quote batches under load |
Still out of scope
These stay off the roadmap on purpose:
- Replacing the human webshop for click-to-order customers
- Letting software rewrite diet or budget without a new signed slip
- Free-roaming agents that invent prices or quantities
- Building Valio Aimo’s full marketplace
- Letting monitoring or language models authorize spend
Shipped baseline (Junction 2026)
Ask → signed offers → rules → human sign → confirmation → audit · open API + MCP · on-time risk and greenest mode · learning with eval gate · Telegram, voice, photo · fifteen guardrails · live demo site.