Running a business already asks you to make enough decisions. Which client needs attention. What to deliver next. Where to spend your time. Choosing an AI model for every piece of work should not become another job.
We’re building Amolfi Pear to take that choice off your plate. Pear is our orchestration model: the system that chooses which AI model should handle a task and how much reasoning it needs. The aim is simple. Choose Pear, tell your Amo what you want done, and focus on the result.
Different work needs different intelligence.
Reading a short support request and preparing a complex client proposal ask different things of AI. One may need a quick decision. The other may need careful reasoning across several sources. Sending both to the same model means choosing a compromise before the work has even started.
An expensive default can make routine work cost more than it needs to. A cheaper default can leave difficult work without enough reasoning behind it. And as new models arrive, the choice changes again.
Pear’s design starts with the task. Routine work can begin with an economical model. More demanding or uncertain work can start with a more capable one. Work that needs a browser or web search goes to a model equipped to use those tools.
We’re also designing a way to step up when a task turns out to be harder than expected. That change belongs between turns or when handing off a subtask, so useful context can carry forward.
The work should determine the intelligence it gets.
One experience, with more behind it.
Pear brings models together. The models that write answers come from other providers; Amolfi builds the system that chooses between them and connects those choices to the work your Amo is doing.
That distinction matters. Building Pear means working on the decisions around an answer as well as the answer itself: where to begin, which tools a task needs, and when another model should take over.
It also gives us a way to keep evaluating new models and improving the choices behind Pear. Keeping up with that changing landscape belongs with us. The business owner’s choice should remain simple.
Small decisions deserve their own design.
An agent using a browser makes many small choices. Which field is the billing postcode? Which control opens the next section? Is there enough information on the page to choose at all?
A general chat model is built to produce an answer. For these moments, we built a decision engine around a narrower question: which of these options fits? It returns a choice with a confidence estimate. If the estimate is too low, or the options are too similar, the engine can leave the decision to the main model.
The current engine uses a hosted model and has been tested in development. We plan to build a compact decision model of our own for this role. That is a next step in Pear’s development, with its own training and evaluation work still ahead.
Built by testing the choices.
We started with pages recorded as an agent’s browser sees them, questions about those pages, and known answers. Then we tested against a separate set created without access to the prompts being developed. That separation helped reveal problems the original examples had missed.
Some of the findings changed our approach. In our development tests, asking the same question repeatedly and voting on the answers made the result worse. Showing the page once, instead of repeating it for each question, helped the engine make better choices.
Those experiments shaped Pear around a practical principle: improve the information a decision is based on, then test whether the decision actually improves. More calls and more reasoning are useful only when they help the work.
Built around a business day.
Consider three situations that guide the design. These illustrate how we intend Pear to fit into everyday work.
- Sorting support requests. An Amo reads new submissions and organizes them in Tickets. Pear’s economical route is intended for routine reading and classification like this.
- Preparing a client proposal. An Amo brings together earlier results and the next scope of work. Pear’s more capable route is intended for tasks that need reasoning across several sources, with the draft ready for a person to review.
- Working through a web form. An Amo identifies the fields needed for a registration. The decision engine helps choose the right fields; submitting the registration or making a payment remains subject to approval.
The benefit we’re building toward is a better match between the work and the resources used to do it. Routine tasks get an economical path. Difficult tasks get room for more careful reasoning. The person keeps the same conversation with their Amo.
The choices that stay yours.
Choosing a model does not grant an agent permission to act. Pear fits within Amolfi’s approval system: actions such as sending, publishing or making a payment come back to a person for approval.
The decision engine is designed to exclude outward or sensitive actions from the choices it makes. We test that boundary alongside whether it chooses the right field. A fast answer is useful only when it respects the authority the agent has been given.
Where Pear goes from here.
Pear’s routing policy and decision engine have been built and tested in development. We’re working toward bringing Pear into Amolfi on the web, Mac and iPhone, with product integration still ahead.
We’re also developing the option for suitable requests to run on a person’s own Mac or iPhone, with larger tasks handled in the cloud. That device experience and our planned decision model are part of the work ahead.
The ambition is to make choosing AI a quieter part of running a business. You bring the goal. Your Amo does the work. Pear helps choose the intelligence behind it.
