“Make this shorter. Focus on LinkedIn from now on.”
Imagine that message arriving as feedback on a marketing draft. Shortening it is a writing task. But which draft does the sender mean? And does “from now on” apply to this campaign, or to every campaign that follows?
As a founder, I build software that needs to keep track of those agreements. A customer should be able to continue a task without explaining the brief again. That is why I am developing a shared approach for Ensemblo, Sterka and TravelJim, drawing on System One.
My starting point is to design and test the decisions between a request and its result separately. Software retrieves the relevant information and enforces permissions. A model helps interpret language or produces new content. At the end, the system needs evidence of what actually happened.
Where System One, Jev and Qwen fit
TypeSafe uses System One Models to describe models that answer specific questions with structured results. Jev is its first model in this category. You can provide the context of a customer message and ask for a choice from a defined set of options, or a score against stated criteria. Code can then work with that answer. Source: TypeSafe's introduction.
I use that principle in my own design: define the decision first, then decide how to make it. My local experiments currently run on Qwen. Jev is a candidate I want to compare on selected decisions.
Scroll sideways to read every column.
| Name | What it means | Role in my setup |
|---|---|---|
| System One | TypeSafe's name for this category of decision models. | Inspiration for designing individual decisions explicitly. |
| Jev | TypeSafe's model for structured decisions. | A candidate for comparison; it handles no customer traffic here. |
| Qwen3 8B | A generative language model that can also be tested on interpretation tasks. | Runs on my computer for bounded local experiments. |
| My software | Code for context, task assignment, permissions, storage and execution. | Connects a request to the appropriate action and records progress. |
Qwen is a general language model from the Qwen3 family, not a local edition of Jev. I run it through Ollama, which lets the model work on my own computer. Source: the official Qwen3 introduction.
A structured answer can still be wrong. A perfectly formatted choice may refer to the wrong draft. Checking the context remains part of the system's job.
One message contains several decisions
One message, six different jobs
Follow the handoffs between software, models and people. This illustrates a proposed workflow; it is not a running product.
“Make this shorter. Focus on LinkedIn from now on.”
- SoftwareFinds, checks and executes
- ModelInterprets or writes
- PersonClarifies and authorises
Reduced motion is on. Use the steps to follow the explanation.
1. Find the draft
- Available
- The message is attached to an existing draft.
- Result
- The software identifies the draft the message refers to.
- What happens next
- Pass the draft and the complete feedback to the interpretation step.
2. Separate the requests
- Available
- The draft and the full feedback sentence.
- Result
- Current request: shorten the draft. Possible future preference: more LinkedIn. Scope: still unknown.
- What happens next
- Ask what “from now on” covers. This is a written illustration, not a model response.
3. Clarify the scope
- Available
- A preference that could apply to one campaign or future campaigns.
- Result
- The question for the user is: “Do you mean this campaign, or future campaigns too?”
- What happens next
- The scope stays unknown until the person answers. Playing this walkthrough does not choose an answer.
4. Write a shorter draft
- Available
- The original draft, brand rules and the request to shorten it. Any lasting preference needs a confirmed scope.
- Result
- The writing brief would be: “Shorten this draft while preserving the facts and brand voice.”
- What happens next
- Send the resulting draft for a separate review. This illustration generates no new copy.
5. Review and approve
- Available
- The revised draft, the brand rules and the intended publication.
- Result
- A separate review checks the work. An authorised person must then approve publication.
- What happens next
- A request to revise is not permission to publish. No approval has been given in this example.
6. Execute, then confirm
- Available
- The current version, permissions and a valid publication approval.
- Result
- Only with that approval may the software call the publishing connection.
- What happens next
- A confirmation from the connection is still needed. Without it, execution remains unconfirmed.
Back to “Make this shorter. Focus on LinkedIn from now on.” This is how I want Ensemblo to handle that request. It is an illustration of the intended workflow.
Read the six steps as a table
Scroll sideways to read every column.
| Step | Who does the work? | Required result |
|---|---|---|
| 1. Find the intended draft | Software retrieves the customer, task and current text. | Identify the version that needs changing. Ask if the reference is unclear. |
| 2. Interpret the feedback | A model considers the revision and possible preference separately. | An instruction to shorten the draft, plus a proposal to record the LinkedIn preference. |
| 3. Clarify the scope | The system asks the customer what “from now on” means. | Establish whether the preference applies to this campaign or more broadly. |
| 4. Rewrite the draft | A generative model receives the text, feedback and brand rules. | A shorter draft that preserves the facts and brand voice. |
| 5. Review and approve | A separate assessment checks the draft; the authorised person decides. | A usable revision and a recorded decision about publication. |
| 6. Execute and confirm | Software checks permissions and uses the publishing connection. | Confirmation from that connection that the agreed action happened. |
At step 2, the proposed interpretation might look like this in plain English:
Scroll sideways to read every column.
| Question | Illustrative answer |
|---|---|
| What needs to happen now? | Shorten the current draft. |
| Is there a possible preference for future work? | Yes, more emphasis on LinkedIn. |
| What is still unclear? | Which campaigns the preference applies to. |
These answers are written examples, not outputs from a model test. They show how a casual sentence can become a specific next action. The software can ask: “Do you mean this campaign, or future campaigns as well?”
That distinction stops a temporary request from quietly becoming a permanent brand rule. For a stored preference, I want to know who confirmed it and where it applies. A model suggestion must remain identifiable as a suggestion.
If the customer presses a “Make shorter” button, the intent is already known. The writing task can follow once the right draft and conditions are established. Every extra model step needs to solve a problem.
Every extra model step needs to solve a problem.
What I have built so far
In my AI team, an agent is a role with instructions and tools, such as writing or research. That agent uses a model for part of its work. Counting agents tells you little about the models and checks behind them. I describe the roles in more detail in how my AI marketing team works.
Ensemblo, Sterka and TravelJim share code that defines the available decisions and valid answers. Each product keeps its own data and execution code. A rule that ties an answer to the right task can therefore be reused without mixing customer records.
My Windows computer runs the local Qwen and Ollama test environment. It includes storage, temporary reuse of valid answers and recovery after an interruption. Startup at Windows sign-in is configured.
If a required local capability is missing, that route stops with an explicit message; it does not silently make a paid model call.
The build status on 30 September 2026:
Scroll sideways to read every column.
| Component | Status |
|---|---|
| Local components | Built and exercised with test data, including storage, reuse and recovery. |
| Complete handling of customer tasks | Still to be demonstrated. The full local product environment is missing; no program here independently completes real customer tasks. New campaign distribution and outcome measurement have not been released. |
| Jev | Prepared as a candidate for comparison. Not admitted to customer traffic. |
For the feedback example, this means I can investigate individual parts of the workflow. The complete journey from feedback to publication and measured effect remains a development goal.
How this could work in my own products
The responsibilities are similar, but the task changes with the product. Ensemblo, Sterka and TravelJim already connect to the shared decision contracts. The examples below describe what I want those connections to support. For PlainConsent, the application is a possible extension.
Ensemblo: turning feedback into the right next task
For Ensemblo, my AI marketing team for businesses, the LinkedIn example is directly relevant. The decision step needs to identify what the customer wants changed in this draft and which preference also applies to future work. The writer then receives the corresponding instruction.
The same approach could identify missing information in a brief or select the brand sources a writer needs. I would measure the revisions required before a customer accepts a piece, and how often a temporary request is incorrectly stored as a lasting preference.
Sterka: choosing the next step in a coaching conversation
For Sterka, my training and nutrition coach, consider: “I slept badly and only have twenty minutes.” The system needs to establish whether someone wants to change an existing workout, wants an explanation or still needs to make a choice. Existing training rules determine the available options; a model can help explain them.
The potential value is a conversation that retains earlier context and asks a useful next question. I would measure unnecessary questions and misunderstood requests. This example makes no claim of proven health benefits. Sterka is described among the products I build.
TravelJim: turning travel constraints into a workout
TravelJim helps people keep training while travelling. Take the request: “I have twenty minutes and only dumbbells here.” The interpretation step extracts the stated time and equipment. The existing training engine uses those inputs to create an appropriate session.
The intended next step is to continue the same workout through a message, the app or a workout link. A hotel name cannot establish that a gym exists, and reopening a session must not create a duplicate. I would measure how much clarification is needed before someone can start, and whether the correct session is resumed.
PlainConsent: installation help based on verifiable checks
For PlainConsent, my cookie consent product, I see a possible use in installation support. “I added the code, but the banner isn't showing” gives a model a problem to interpret. It could choose a focused question or explanation based on the available technical checks.
Those checks still have to establish whether the script actually loads. Consent remains the visitor's choice; a model response cannot change it. I would investigate whether people reach a verified working installation with fewer exchanges. This is a potential extension, not an existing System One integration in PlainConsent.
What a failed assessment taught me
A local test of complex feedback exposed a problem: the reviewer blocked incorrect proposals, but also rejected valid ones. Users would have to investigate or resubmit good changes. I therefore did not allow that task onto the local production route.
In the LinkedIn example, this could mean a useful revision gets stuck for the wrong reason. Counting only the errors a reviewer catches would miss that cost.
For the next comparison, I want to keep pre-assessed examples separate from those used to improve the instructions. I will count both proposals accepted incorrectly and proposals rejected incorrectly. The work left for a human reviewer belongs in that assessment too.
Lower costs depend on work actually disappearing
An extra decision model earns its place when it replaces other model work, prevents repetition or reduces corrections. If every request still receives the same expensive treatment afterwards, I have added another step.
That makes the cost per correctly completed task the useful measure. A cheap answer can become expensive by the time someone has corrected it. Running a model locally also has costs, including hardware, electricity and maintenance.
Suppose you process 100,000 bounded decisions each month. Under the assumptions below, the existing route costs €396.30. A Jev decision step for all those requests costs €7.40. The volume and existing model rates are assumptions; the Jev rate comes from TypeSafe's model documentation. The calculation is set out at the end of this article.
This is a Jev scenario, not a measured saving from my local Qwen setup. It assumes the two routes ultimately deliver the same quality.
What if more requests still need the existing route?
Compare the existing model route with a Jev decision step. Some requests would then need that full existing route as well. Both bars use the same scale.
- Decision step
- €7.40
- Existing route after the decision
- €79.26
€309.64 lower model costs in this scenario
Only the described model costs, assuming equal quality. This is a Jev calculation, not a measured Qwen saving. Hardware, operations, writing outside these calls and human review are not included.
100,000 decisions per month. The existing route uses 2,000 input tokens and 500 output tokens per decision; the Jev step uses 2,000 input tokens.
See all five scenarios
| Need existing route | Total | Difference from existing route |
|---|---|---|
| 0% | €7.40 | €388.90 lower |
| 20% | €86.66 | €309.64 lower |
| 50% | €205.55 | €190.75 lower |
| 80% | €324.44 | €71.86 lower |
| 100% | €403.70 | €7.40 higher |
Download the comparison as JPG.
Read all four cost scenarios
Scroll sideways to read every column.
| Requests still needing the full existing route | Total monthly model cost | Difference from €396.30 |
|---|---|---|
| 20% | €86.66 | €309.64 lower |
| 50% | €205.55 | €190.75 lower |
| 80% | €324.44 | €71.86 lower |
| 100% | €403.70 | €7.40 higher |
In the first scenario, you pay €7.40 for the decision step plus 20% of the existing cost: €86.66 in total. If every request still needs the full existing route, the decision step adds €7.40 to the bill.
This calculation covers only the bounded decisions. Writing the LinkedIn post, human corrections and other execution work are outside it. For each task, I need to find out how much existing work can actually disappear while quality is preserved.
Where I would start in other businesses
I see potential in businesses that receive repeated requests and have useful records about the customer, order or task. These are applications I infer from the approach, not proven results for these industries. TypeSafe describes related patterns for recognising requests and routing work. Source: TypeSafe's architecture patterns.
Scroll sideways to read every column.
| Business type | Example decision | Potential value and what to measure |
|---|---|---|
| Online shops and D2C brands | Is a message about delivery, a return or product advice, and which order does it concern? | Less investigation. Check whether the request reaches the correct workflow with the correct order details. |
| SaaS companies | Is a message a usage question, a bug report or a feature request? | More focused support. Measure incorrect routing and the extra information staff still need to request. |
| Professional services | What information is missing before an enquiry can be assessed? | A more complete brief for the first substantive conversation. Measure unnecessary questions and correction time. |
| Fitness chains, hospitality and other businesses with multiple locations | Which local details and approvals belong to a campaign? | Less repeated research and fewer mixed-up offers. Check that the location, price and approval belong together. |
| Marketing agencies and content teams | Does feedback apply to this draft or to future assignments? | More precise revisions and usable brand preferences. Measure accepted revisions and preferences stored incorrectly. |
Execution remains a separate step in all these cases. Recognising a return request does not grant permission to refund it. Recognising a feature request says nothing about when it will be built.
Start with enough repetition to justify the integration and upkeep. Unreliable records or unclear approval rights need fixing first. A unique strategic problem still calls for extended thought.
More room for the founder's work
As a founder, I can see a useful foundation taking shape. I can investigate the same components for context, task assignment and progress across several products. For each task, I can decide whether code is enough, whether a local model is useful or whether another approach is still needed.
For a marketer, some of the work shifts towards making professional judgement explicit. Which sources may a writer use? When is a revision acceptable? Which agreement carries over to the next piece? Those choices determine whether the system helps the customer or creates more corrections.
The opportunity for entrepreneurs is to reduce that repeated work. If an ordinary revision needs less explanation and repair, there is more room to improve a message or test an offer. Measurement has to establish whether that capacity actually becomes available.
My next step is to follow one confirmed task through the whole process, including execution and its result. The customer keeps control of the direction. The software should carry more of the agreements and follow-up work.
Take one recurring request from your own marketing process. Write down the information it needs, who approves it and what would prove it is finished. That gives you a first task you can design and test with a clear purpose.
Assumptions and calculation
A token is a piece of text that a model processes. This scenario gives each decision 2,000 input tokens. The existing route also produces 500 output tokens. The monthly volume is 100,000 decisions. These are chosen inputs for the calculation.
Scroll sideways to read every column.
| Rate per million tokens | Amount in euros | Basis |
|---|---|---|
| Existing route, input | €0.880669 | Assumed rate from the original example, converted. |
| Existing route, output | €4.403347 | Assumed rate from the original example, converted. |
| Jev, input | €0.036988 | Published provider rate, converted. |
| Jev, output | €0.00 | TypeSafe does not charge for output tokens. |
The Jev rate was checked on 30 September 2026. Conversion uses the ECB reference rate for 30 September 2026: 1 euro equals 1.1355 US dollars. Source amounts were divided by 1.1355. The displayed rates are rounded; the results use unrounded values.
- Existing route: 100,000 × (2,000 × €0.880669 + 500 × €4.403347) / 1,000,000 ≈ €396.30.
- Jev decision step: 100,000 × 2,000 × €0.036988 / 1,000,000 ≈ €7.40.
- Combined route at 20% additional treatment: decision cost + 0.20 × existing cost ≈ €86.66.
The assumed Jev input includes the question. Each exception receives the full existing treatment. Equal final quality is assumed; any extra work to detect exceptions or assess answers is not separately budgeted. Hardware, electricity, maintenance, human work, writing and the rest of the product are outside this model-cost comparison.