Komerz OS
From a research question to a business plan you can sign.
- Commerce and Finance
- AI, Agents & Data
- Application Development
- Technology Consulting
01In short
Komerz OS in short
An AI commercial-planning platform for consumer brands. A research agent answers where to play, then a planning workspace builds how to win, down to a P&L that reconciles.
- Product
- Komerz OS
- Domain
- Commerce and Finance
- Category
- AI platform · Commercial planning
- Platforms
- Web workspace, Research agent, Serverless platform
- Services
- Technology consulting, AI agent engineering, Product design, Platform engineering
- Year
- 2026
- −66%Time to first workbook
- 0.00Unallocated P&L balance
- 1,874Automated tests
- 5 moFirst commit to V4
02Context
The story of Komerz OS
Challenge
Komerz helps consumer brands decide where to play and how to win: which markets, channels, prices and packs, and what the P&L looks like if they get it right. The method lived in consultants' heads and spreadsheets. Komerz wanted it as software: a research partner that answers commercial questions, then turns the answer into a plan a brand can take to a buyer or a board.
Approach
Komerz OS is two workspaces joined by one bridge. Where to Play is a research chat that reads the brand's own files, Komerz's proprietary market data and the public web, and answers with citations, reports, decks and workbooks. How to Win turns that research into channels, competitor pricing, price and pack, value chains, volume plans and a monthly P&L.
We rebuilt the platform from the ground up on a serverless AWS stack, with an agent that orchestrates specialist models and a set of deterministic engines that own anything a finance team has to trust. Convert to project carries the whole conversation, its files and its template choices into the plan, so nothing gets typed twice.
Insight
Let the model make the judgment calls. Never let it do the maths.
Language models are brilliant at reading a market and terrible at being a calculator: a confident wrong number looks exactly like a right one. So we drew a hard line through the system. Models decide what matters and which template fits; compilers, evaluators and budgets decide what gets computed, what runs and when to stop. Every hard problem in the project came back to where that line sits.
2 hard problems
- P01Make an AI build a P&L without inventing a single number.How do you let a model draft a three-year business plan when one plausible wrong margin can sink the deal it was built for?
- P02Let an agent think for twenty minutes on compute that quits at fifteen.How do you run deep, multi-step research in a multi-tenant product, where every turn is bounded, survives a crash and pays for each search exactly once?
03Numbers you can sign
Hard problem 01 of 02
Make an AI build a P&L without inventing a single number.
How do you let a model draft a three-year business plan when one plausible wrong margin can sink the deal it was built for?
A brand takes this plan to a retailer, an investor or its own board. Text can be a little wrong and still be useful. A P&L can't. Every figure has to trace back to a price, a margin, a cost or a stated assumption, and the workbook has to keep computing when someone changes a number at 11pm before the meeting.
Why it’s hard
- F.01Models write formulas like poetsAsk a model for a spreadsheet and it invents costs, breaks cell references and builds circular logic, all formatted beautifully.
- F.02Every channel has its own waterfallThe path from shelf price to manufacturer cost changes with the market and the route: tax, retailer margin, distributor margin, platform fees, promotions.
- F.03Unknown is not zeroA missing cost silently treated as zero turns into invented profit. The system has to carry not-knowing all the way to the bottom line.
- 01FrameFind the valuable decision, workflow or experience.
The risk isn't a bad sentence. It's a believable number.
We traced how a Komerz consultant actually builds a plan, from the shelf price down to what the manufacturer keeps, and marked every point where an AI could make a number up. That reframed the brief: the job wasn't to make the model better at spreadsheets, it was to take the arithmetic away from it entirely.
- Mapped the price waterfall from MRP and SRP to manufacturer COGS
- Catalogued Komerz's value-chain templates by market and channel
- Set the rule: unknown values stay unknown, everywhere
- 02DesignShape the interaction, context and control model.
Split judgment from arithmetic.
We designed a control model with two owners. The model chooses: which products, which routes, which template fits and which scenario inputs to try, each with a stated reason and confidence. A compiler owns every formula. Edits follow the same split: you say what to change, the engine decides what that does to the plan.
- The model picks portfolio, route, template and scenario inputs
- The compiler writes every cell formula from live admin templates
- Evidence graded strong, usable, directional or rejected
- 03EngineerBuild the intelligence, agent and tool chain.
A compiler for commercial logic.
Komerz's templates are written as row references, like R1 × R4. The compiler translates them into live Excel formulas, works out each row's role in the P&L from the waterfall, and refuses to build if net sales minus variable spend doesn't reconcile to manufacturer cost. The same formula engine runs in the agent and the API, held identical by a parity test, so a number in chat matches the number in the workspace and the download.
- Formula graph checked for cycles and missing references before build
- Reconciliation gate: the waterfall must close or compilation stops
- Edits like 'make it 250 doors' patch one input and re-evaluate the lot
- An edit is rejected if any formula would newly fail
- 04ProveEvaluate performance, safety and economics.
Audit every template, then reconcile to the last decimal.
When one production run hit a circular reference, we didn't patch that template. We audited all of them. Three formula defects came out, including a value chain that ran backwards. Every template now compiles a full 8-sheet, three-year forecast as a test. Then we ran a live brand plan end to end and reconciled it against the source data.
- 9 of 9 templates audited and compiled as 3-year forecasts
- 3 template defects found and fixed, one a reversed waterfall
- 2,704 generated formulas evaluated with zero errors
- Unallocated balance on a live brand plan: 0.00
- 05OperateDeploy, observe and improve in the real workflow.
Fast first, then right, then both.
Research workbooks got the same treatment in production. One planning call designs typed columns, tabs are written in parallel, every row is mapped to its source, and the file is published first and verified after. Only the tabs that fail get repaired; passing tabs are kept byte for byte. Edits are routed by where a workbook came from, so a compiled plan never gets rewritten by a generic writer.
- First downloadable workbook in 4m18s, down from 12m47s
- Writer context cut by about 86% per tab
- Replays of real workbook runs catch regressions before release
The answer · Numbers you can sign
The model makes the calls. The compiler does the maths.
- 0.00Unallocated balance on a live plan
- 2,704Formulas, zero errors
- 9/9Templates audited and compiled
- −66%Time to first workbook
04Twenty-minute thinking
Hard problem 02 of 02
Let an agent think for twenty minutes on compute that quits at fifteen.
How do you run deep, multi-step research in a multi-tenant product, where every turn is bounded, survives a crash and pays for each search exactly once?
A real commercial question takes real work: read the attachments, search proprietary data, search the web, find the gaps, search again, then build a deck or a workbook and check it. That can take longer than a serverless function is allowed to live. And every repeated search or model call is money the client pays twice.
Why it’s hard
- F.01A hard deadlineA Lambda function stops at fifteen minutes and an HTTP request gives up long before that. The work doesn't care.
- F.02Retries cost moneyPlatforms retry failed work. Without care, a retry re-runs paid searches and model calls, or two workers answer the same prompt.
- F.03Freedom versus safetyA rigid classifier can't handle real conversations. An agent with free rein can't be trusted with many companies' private data.
- 01FrameFind the valuable decision, workflow or experience.
The first version asked permission for everything.
The original flow sent every message through a classifier with three buckets, then a keyword allowlist. It was predictable and it broke on the second follow-up. Watching real conversations showed what users wanted: an analyst who decides for itself when to search, when to stop and when to build something.
- Studied real turns: 5 to 15+ minutes of research and building
- Listed what must never happen: double billing, data leaks, a silent failure
- Chose a ground-up serverless rebuild over scaling the old app
- 02DesignShape the interaction, context and control model.
Bounded agency.
Our rule: the model decides whether a capability is needed; guarded tools decide how it runs. The agent gets about a dozen tools, such as inspect an attachment, search proprietary data, search public sources, check coverage, create an artifact. It gets no shell, no raw filesystem and no code execution. It works inside budgets it can see, and it can only create or change a file when the user's words grant it.
- 12 tool calls, 10 public searches and 32 model calls per run
- 'Fix it' grants an edit; 'don't change it' grants nothing
- A private-term filter keeps client data out of public search, always on
- 03EngineerBuild the intelligence, agent and tool chain.
Work that outlives the machine running it.
The API accepts a prompt and returns immediately. The agent runs on its own and streams planning, thinking, task and answer events back over a real-time subscription. An idempotent lease ensures one prompt has one owner. Fingerprinted checkpoints on a per-chat file system keep every finished search and plan, so a worker that takes over picks up the evidence instead of paying for it again. Decks, workbooks and project builds run on their own workers and step functions, with dead-letter queues behind them.
- Async invoke plus AppSync subscription instead of a long HTTP call
- DynamoDB lease: one prompt, one owner, even under retries
- Checkpoints keyed to prompt, files, sources, pipeline and models
- Project builds fan out per product and channel, six at a time
- 04ProveEvaluate performance, safety and economics.
Break it on purpose, and write down what broke.
The first agentic build did worse than the old one: five of six runs crashed. We said so in writing, ran three independent review rounds and fixed what they reproduced. Every change since ships with a dated report: root cause from traces, the fix, the tests, and the same prompt run live against production for comparison. Transport tests fast-forward time to prove 18- and 50-minute turns still land.
- 1,874 automated tests across the platform
- 18 agent and conversation eval scenarios, from pause-and-resume to topic shifts
- Token-limit recovery tested against the live model with a forced tiny budget
- 05OperateDeploy, observe and improve in the real workflow.
Every bill itemised. Every change reversible.
In production, each model call records its tokens, cached tokens, reasoning tokens and why it stopped, priced from a versioned catalogue across four providers and rolled up per prompt, user and month, with limits admins can set. Every major change ships behind a flag, from shadow to canary to default, with the previous path kept as an instant rollback. When a deck once took eighteen minutes, the trace showed a parser timeout being read as broken code; after the fix, the next live deck needed zero repairs.
- Per-run cost accounting with monthly limits per user
- Truncated answers retry once with double the budget, never re-running tools
- Context capped after one saved plan inflated a turn to 516k tokens
The answer · Twenty-minute thinking
The model decides what to do. The system decides how far it may go, and remembers where it stopped.
- 50 minLongest turn proven in tests
- 1×Each paid search, even on retry
- 1,874Automated tests
- 18Agent eval scenarios
05Glimpse of the product
A glimpse of the product.
Tap a screen to enlarge
06FAQ
Questions about Asymmetri.
Asymmetri builds AI agents that run in production. For Komerz OS, a commercial-planning platform for consumer brands, Asymmetri built a multi-tenant research agent on AWS that handles turns of twenty minutes or more, survives retries and crashes without repeating paid work, and is covered by 1,874 automated tests and 18 agent and conversation evaluation scenarios.
Asymmetri separates judgment from arithmetic. Language models make the judgment calls, such as which products, channels and templates fit, while deterministic engines compute every number. On Komerz OS a template compiler writes every P&L formula, refuses to build a plan that does not reconcile, and keeps unknown values unknown instead of treating them as zero. A live brand plan reconciled to an unallocated balance of 0.00, with 2,704 generated formulas evaluating without errors.
Asymmetri designs cost in from the start: hard budgets per run (for Komerz OS, 12 tool calls, 10 public searches and 32 model calls), checkpoints so a retry reuses finished searches instead of paying again, context caps, and per-call cost accounting across every model provider with monthly limits per user. Smaller context also made the product faster: the first downloadable workbook arrives 66% sooner.
Yes. Asymmetri runs agent work that outlasts a single serverless function by invoking it asynchronously, streaming progress over real-time subscriptions, giving each prompt one owner through an idempotent lease, and checkpointing finished work to a durable per-conversation file system. On Komerz OS, built on AWS Lambda, AppSync, Step Functions, DynamoDB and S3 Files, tests prove turns of up to 50 minutes complete against a 15-minute function limit.
Asymmetri is model-agnostic and routes each job to the model that does it best. Komerz OS uses Claude on Amazon Bedrock to orchestrate, with OpenAI and Google Gemini models for research, planning, writing and repair, on an AWS serverless stack defined in AWS CDK, with a Next.js front end and Langfuse tracing.
Komerz OS went from first commit to its fourth major version in about five months, as a ground-up serverless rebuild of the earlier platform. Asymmetri ships every major change behind a feature flag, moving from shadow to canary to default with the previous path kept as an instant rollback, so speed does not cost stability.
Asymmetri is a hard problems technology company. It engineers AI systems, agents and digital products for global brands, across four areas: intelligence, process, experience and scale. Asymmetri works through four practices: AI agentic systems and data, application development, technology consulting, and innovation and R&D.
Every Asymmetri engagement runs one loop with five stages. Frame: find the valuable decision, workflow or experience. Design: shape the interaction, context and control model. Engineer: build the intelligence, agent and tool chain. Prove: evaluate performance, safety and economics. Operate: deploy, observe and improve in the real workflow. The loop repeats, so each pass lands closer to the target. Asymmetri's case studies show each hard problem moving through it.
Send a short brief through asymmetri.in/contact-us or email hey@asymmetri.in: the problem, what's in the way and your timeline. No deck or RFP is needed. Asymmetri replies to set up a framing conversation, then proposes a prototype or pilot with scope, team, timeline and what success looks like.
07More work