Hone wants to replace tasks with measurable business outcomes

Hone Engines replaces the prompt with an economic outcome metric. What this P&L-driven steering changes for agent governance in the enterprise.

Hone introduces Engines, a new category of enterprise agents that are no longer simply given tasks to execute, but business outcomes to achieve. The company summarizes its positioning as follows: chatbots answer, agents accomplish tasks, and Engines must take responsibility for an objective and be evaluated on the actual economic value created.

An Engine can thus receive an instruction like "improve customer retention" or "increase qualified pipeline," and then determine for itself the necessary steps, the people to involve, the tools to use, and the specialized agents to create. Hone presents this architecture as a persistent system that continues to pursue its objective when conversations stop or conditions change.

The launch is accompanied by a $60 million seed round, led by Benchmark and Index Ventures with Elad Gil, Hanabi, Definition, Diffusion, Lux, SV Angel, and Align. Index describes Hone as a layer situated between frontier models and the enterprise, capable of transforming their capabilities into continuous operational processes. The objective replaces the prompt

The difference claimed by Hone lies primarily in the level at which the user intervenes.

With a classic assistant, you have to formulate a question. With an agent, the user generally delegates a task or an already identified workflow. An Engine instead receives an outcome metric, along with the boundaries within which it can act.

Hone gives the example of customer retention. The organization defines the expected outcome, and then the system begins by understanding the business before determining its action plan. It can analyze the tools used, processes, history, constraints, decision-makers, and existing practices.

The company claims that the Engine can then identify on its own new responsibilities or strategies likely to improve its KPI.

This way of operating brings the system closer to an organizational role than to a one-off automation. Automatic onboarding before taking action

Before its deployment, an Engine builds a representation of the environment in which it must work.

It ingests the systems, history, and knowledge necessary for its role, identifies how decisions are made, and learns what constitutes a good outcome for the organization.

On Hone's website, this phase also takes the form of training on the company's actual history.

The Engine can replay past tickets, sales opportunities, decisions, or situations to show what it would have done. Human teams then correct incorrect behaviors before authorizing the system to intervene in real operations.

This simulation logic constitutes one of Hone's most interesting technical building blocks. Testing its own changes before production

Hone details this mechanism in a research paper published alongside the launch.

When an Engine modifies its own instructions, its memory, or certain routines, these changes are first tested in a replay environment that reproduces the historical state of the company. The system can thus verify the impact of a modification before promoting it to production.

Hone compares this principle to the classic improvement cycle of a software system: observe a problem, modify the system, test, and then deploy.

The difference is that the Engine itself receives some of the tools allowing it to perform this loop.

In an experiment conducted by Hone across 125 scenarios, using these replays reportedly reduced the regression rate from 33% to 5%. Without simulation, agents were notably unable to correctly predict which existing capabilities would be broken by their own modifications.

These results are internal to Hone, but they show the type of problem the company is trying to solve: allowing a persistent system to improve without silently deteriorating what it already knew how to do. Engines write their own routines

This improvement also goes through an Engine repository.

According to Hone, each Engine can write the routines necessary for its work and then keep them in a versioned repository. When a task becomes repetitive, the system can therefore transform a previously improvised procedure into code or a reusable workflow.

This mechanism combines with an organizational memory.

Engines retain user preferences, internal practices, and accumulated learnings across multiple people and multiple executions. When a team member makes a correction, it can improve the system's behavior for the entire organization.

Hone particularly emphasizes this point: knowledge acquired over time must not disappear when a conversation is closed, nor remain locked in the weights of a model accessible to everyone. It must become a form of operational capital specific to the enterprise. A fleet of agents under a single objective

An Engine is not necessarily a single agent.

Hone uses an agent orchestration layer capable of creating or coordinating multiple specialized agents to handle different parts of an objective. These can be distributed over several tasks and then collaborate with the humans involved.

This architecture recalls the distinction gradually emerging between the model, the agent, and the harness surrounding it.

At Hone, the Engine represents the persistent layer that owns the expected outcome. The agents become temporary or specialized execution units used to achieve this outcome.

The real product therefore lies in the orchestration, memory, evaluations, and governance mechanisms that persist above the models. Humans remain in the workflow

The autonomy claimed by Hone does not mean that Engines have unlimited access.

They work directly within the tools used by teams, notably Slack, Microsoft Teams, and email. Users can hand off work to them, make corrections, or take back a task.

Policies can also mandate human validation before certain sensitive actions.

Each action is associated with permissions and logged to allow for subsequent auditing. Hone indicates that execution is sandboxed, that data is encrypted in transit and at rest, and that it is not used to train models. The infrastructure