Product concepts, shown with how they would work.
Nothing here is a launched product. Each concept shows the problem, the proposed flow, and what we would need to validate before building it, with an honest status on every one.
Request routing with human review.
The problem. Small teams get a steady stream of requests, such as customer emails, quotes and internal tickets. Sending all of them to one large AI model is slow and costly. Sending none is slow in a different way. The concept sorts each request, sends it to the right model, and keeps a person in charge of anything that matters.
Step 1
Business request
An email, form or ticket arrives.
Step 2
Classify the task
Contains customer records, so it must stay inside the approved boundary.
Step 3
Choose the route
- Approved private deployment
- Fast model
- Reasoning model
Step 4
Validation and human review
A person approves before anything is written back.
Step 5
Existing business system
Approved output is written through the system's own API.
Prioritise data control
The proposed flow sends suitable tasks to a private deployment, with access limited to the information the requester is already allowed to see.
- What it focuses on
- Deployment, permissions, data boundaries and running overhead.
- The trade-off
- Private hosting costs more to run and maintain than a hosted model API.
- What we would validate first
- Which request types must never leave the boundary, and who signs that off.
Concept demonstration. This illustrates the proposed experience and flow, not a deployed system. The actual design would depend on the client's workflow and data.
The engineering underneath.
Business owners can stop at the outcome. Technical buyers can open the detail.
Architecture, data boundaries and trade-offs
- Deployment options
- A private deployment on the client's own cloud or server for sensitive data, or a hosted model API for routine work. Chosen per workflow, not per company.
- Model choices
- A small, fast model handles routine classification and drafting. A larger reasoning model is used only when the task needs it. Open-source models are an option where data cannot leave the building.
- Data boundaries
- The classifier sees the request and a short policy, not the whole database. Retrieval only returns documents the requesting user is already allowed to see.
- Integrations
- Read access first. Writes into the business system happen only after review, through the system's own API or a queue.
- When the system is unsure
- If the classifier is not confident, the request goes to a person instead of the system guessing.
- Trade-offs
- Private hosting costs more to run. Fast models cost less but miss more on unclear requests. Human review adds delay, so it is applied by risk level.
What we would check before building
- Which requests in a real sample are routine and which are risky.
- What error rate a reviewer would accept before trusting the fast path.
- The running cost per request on each route.
- Where the existing business system allows safe write access.
How we label every concept
- ConceptThis page
- The proposed design and how it would behave.
- Prototype
- An early build that shows selected capabilities.
- In development
- Active build work is underway.
- Available
- A usable product exists, under stated conditions.
Have a workflow like this?
Tell us how requests reach your team today. We will say whether this approach fits, and what a small first version would cost to test.