Knowledge
as a Service

Execution is no longer for sale. Knowledge is. This is the premise behind Osven: as more of the doing can be delegated to software, the scarce contribution moves toward deciding what should be done, under which constraints, and to what standard. It is a direction of travel, not a claim that execution has already become free or that every occupation can be automated.

A traditional engagement bundles several different things. A client buys an expert’s understanding of the problem, their method, their time, the production of an output, and some responsibility for the result. Those components have usually arrived together because separating them was difficult. The same person who recognised a good answer also had to spend the afternoon making it.

An agent creates the possibility of a different arrangement. The expert specifies a repeatable approach, provides examples, defines checks, and decides where the system must stop. Software performs parts of the work inside those boundaries. The expert can then spend more attention on exceptions, new situations, and improving the method itself. The valuable contribution remains human even when a person is no longer present for every execution.

This changes the question a company asks. Instead of only asking who has time to complete a task, it can ask whose judgement it wants applied repeatedly. A useful agent is therefore more than additional capacity. It is a way of making a particular standard of work available when its author is elsewhere. Whether that standard survives repeated use is the central test of this thesis.

Knowledge here means a working method that changes decisions. It includes the order in which an expert investigates a problem, the evidence they trust, the tradeoffs they accept, and the conditions under which they refuse to proceed. A folder of documents may support that method. It does not, by itself, constitute one.

Consider an experienced operations specialist reviewing a broken fulfilment process. The obvious task is to draw a better workflow. The more valuable work may be noticing that the reported bottleneck is a symptom, asking for the right missing data, and rejecting a change that would improve speed while making errors harder to detect. Expertise lives in those choices as much as in the final diagram.

Some of this judgement can be made explicit through instructions, worked examples, counterexamples, decision rules, and evaluations. Some remains difficult to express. Osven’s premise does not require a complete digital copy of a person. It requires a useful, bounded part of their expertise to perform reliably enough that another organisation wants to use it.

The boundary matters. An expert might have a broad career and a narrow agent: excellent at reviewing a particular kind of brief, but unable to lead an unfamiliar business transformation. A clear statement of competence is more valuable than a sweeping promise. The product should explain what the method covers, what evidence it needs, and what remains outside its remit.

We use the word agent to mean a system that can pursue a defined task using instructions, context, and permitted tools. It may gather information, propose a plan, create an artefact, check its work, and request a decision. Autonomy is a configurable property of that system. It should expand only when its performance and the consequences of a mistake justify the expansion.

Authorship makes the system specific. The author maintains the method, chooses the evaluation cases, and decides which changes count as improvements. A general model supplies capability; the expert supplies a standard and a discipline around its application. Neither is sufficient on its own. A strong method can still fail when given inadequate context or unsuitable tools.

The agent needs a readable specification: purpose, required inputs, permitted actions, expected outputs, checks, and escalation conditions. A prospective customer should be able to understand these before connecting a business system. “Helps with marketing” is too broad. “Reviews a campaign brief against this positioning framework and returns evidence-backed revisions for approval” is a scope that can be tested.

An authored agent also needs a maintenance history. Methods change, models change, and customers discover edge cases. Each meaningful release should identify what changed and how it was evaluated. A customer may want to test a new version before adopting it. Trust depends partly on knowing which version produced a result and being able to reconstruct the relevant decisions.

Imagine a positioning specialist who has developed a method for turning customer interviews into a sharper commercial brief. The following is an illustrative workflow, not a claim about an existing customer or a capability already available in the beta. It shows how a service might become repeatable without treating every judgement as automatic.

The specialist first defines the assignment. The agent can analyse approved interview transcripts, distinguish customer language from internal assumptions, identify conflicting evidence, and draft a positioning brief. It cannot invent interviews, publish a campaign, or rewrite the company’s strategy without review. The customer supplies the source material, business context, and a person responsible for accepting the work.

The first run is a calibration exercise. The agent produces a draft with references back to the supplied evidence. The specialist checks whether the method was followed; the customer checks whether the brief reflects the business. If those reviews expose missing context, the system asks for it. Completing a plausible document is not success when its central conclusion rests on information nobody provided.

Once the assignment is understood, subsequent work can reuse the method with new inputs. Routine checks happen within the workflow. Ambiguous interviews, conflicting objectives, or a request outside scope trigger a human handoff. The customer receives both an output and a record of unresolved decisions. The expert gains a way to deliver their method repeatedly while reserving attention for the work that still requires them.

The commercial unit could be a reviewed brief, a recurring research cycle, or access to a maintained capability. The right unit depends on what the customer can evaluate and what the expert can responsibly promise. The point is to separate the reusable method from the hours needed to supervise a particular engagement, and make both visible.

Saying that an expert owns an agent is not enough. Ownership needs to be expressed as specific rights and practical controls. At a minimum, a service should make clear who controls the method, who can modify it, who can offer it commercially, and what can be taken away when a relationship ends. These are design requirements for Osven, rather than a substitute for the agreements that will define them.

Several assets coexist inside one engagement. The expert contributes an authored method. The customer contributes business information and access to its systems. A model provider supplies an underlying capability. The engagement produces outputs and operational records. Treating all of these as one undifferentiated asset obscures the interests of everyone involved.

Our proposed starting point is to keep the reusable method distinct from customer context. Access to one company’s information should not silently become permission to use it for another company. Improvements derived from an engagement need a clear policy, including what may be generalised and what remains confidential. Customers should be able to understand those boundaries before sharing material.

Portability is another test. An expert should know which instructions, examples, evaluations, and records they can export. A customer should know how to retrieve its own material, disconnect tools, and end access. Technical dependencies may make perfect portability impossible, but those dependencies should be visible. Ownership becomes meaningful when the product gives people usable controls, rather than only reassuring language.

Responsibility also needs a named counterparty. An agent cannot resolve a disagreement about the scope of a service by itself. The expert, customer, and platform each need explicit duties, including who reviews exceptions and how a disputed result is handled. The eventual terms will have to reflect the activity and jurisdiction involved; a single slogan cannot settle those questions.

Knowledge as a service is a proposed commercial model: ongoing access to an expert’s maintained method, delivered partly through an agent. The customer pays for a capability and the quality of its application. The expert earns from repeated use of their expertise, while remaining responsible for the work of keeping that capability useful.

Repeatability does not mean unlimited scale. Each engagement consumes model and tool usage, onboarding effort, monitoring, support, and sometimes human intervention. Some methods also require expensive updating as their domain changes. An agent that generates many outputs but creates an equally large review burden may have weak economics even when its raw execution appears cheap.

A useful accounting model starts with revenue and subtracts execution costs, service delivery, and the cost of maintaining the method. Human review belongs in that calculation. So do retries and failed assignments. The measure that matters is not how many tasks an agent attempted, but how much accepted, useful work it delivered at a sustainable total cost.

Pricing can take several forms. A subscription can suit recurring access to a stable capability. A price per accepted deliverable can suit a well-defined output. A hybrid can combine access with a separate allowance for expert review. Charging for outcomes may align incentives, but only where outcomes are observable and the parties can distinguish the agent’s contribution from external factors.

The opportunity for the expert is to build an asset whose value is less tightly tied to a calendar. That opportunity is earned through quality, repeat demand, and efficient supervision. Osven should make those variables legible. It should not imply that packaging a method automatically creates passive income or that a customer can avoid the work of directing its own business.

A persuasive demonstration proves that a system can succeed once under selected conditions. A service needs evidence that it can be relied on across the assignments it claims to handle. That distinction should shape how an agent is presented, evaluated, and deployed. Reputation alone cannot replace testing on work that resembles the customer’s actual needs.

Before deployment, the author should assemble representative cases, difficult cases, and cases the agent is expected to decline. Evaluation should cover more than the final answer. Did it use the correct evidence? Did it respect the scope? Did it ask for missing information? Did it avoid an action for which it lacked permission? A polished output can hide a flawed process.

During an engagement, authority should follow the consequences of an action. Drafting a private note, modifying a shared record, and sending a message to a customer are different commitments. A service can allow some actions automatically and require approval for others. The controls need to be understandable to the person granting access and practical enough to use every day.

When something goes wrong, the workflow should help contain the problem. That means being able to stop a run, revoke an integration, inspect the relevant record, and identify the owner of the next decision. Where an action can be reversed, the recovery path should be known in advance. Where it cannot, the approval boundary deserves particular care.

The best handoff is a useful handoff. It carries the original objective, the evidence examined, the work already attempted, the uncertainty, and the decision requested. Simply forwarding a long transcript moves effort onto the reviewer. A well-designed escalation preserves the efficiency of the service while acknowledging the point at which automation is no longer appropriate.

If specialised methods can be accessed as services, a company can organise some of its work around a portfolio of capabilities. One service may examine a commercial brief; another may reconcile a defined set of operational records; another may review a release against a quality standard. Each has a scope, an owner, and an interface to the rest of the organisation.

Coordination becomes a central problem. Two individually useful agents can produce incompatible recommendations. A local optimisation can damage a broader objective. Someone still has to decide priorities, settle conflicts, and understand the business as a whole. The company retains responsibility for those decisions even when more of the supporting work happens through services.

Context is therefore an operating asset. A company needs maintained objectives, definitions, constraints, and sources of truth. It also needs to decide which service may see which information. Purchasing an expert method does not instantly supply this context. Onboarding is a real phase of the work, and its success should be judged by whether the service can operate within the company’s actual conditions.

This does not require every company to eliminate employment. Some work benefits from deep internal relationships, physical presence, long-term accountability, or judgement that resists specification. Our thesis is narrower and more useful: where a method can be bounded and evaluated, buying access to it may become an alternative to buying the author’s time for every use.

The organisational skill is knowing which arrangement fits which problem. Keep strategic responsibility clear. Use authored agents where their scope is credible. Bring people directly into work that demands them. A small team may gain access to more expertise, but it will still need the judgement to commission it well.

A career can accumulate more than completed assignments. It can accumulate a method, a body of examples, an evaluation practice, and a reputation for a particular standard. An authored agent offers a way to make parts of that accumulation usable by others. The work of building it can also reveal where an expert’s own approach remains implicit or inconsistent.

The starting point need not be a comprehensive digital counterpart. It may be one recurring decision that an expert understands unusually well. Document the inputs it needs. Describe what a strong answer looks like. Collect failures. Separate the situations where the method works from those where it should be abandoned. A narrow, dependable service is a stronger foundation than an expansive persona.

Learning remains essential. Practical experience gives a person the feedback needed to recognise errors and update their judgement. If an expert delegates every task before developing that understanding, they may become less able to supervise the output. Agent-assisted work should preserve routes for people to practise, investigate, and learn from the cases the system cannot resolve.

Education, in this model, gives more attention to framing problems, checking evidence, comparing alternatives, and making standards explicit. It still needs domain foundations. Someone cannot reliably judge a reconciliation, a design, or an experiment without understanding the underlying work. The opportunity is to connect that understanding to repeated application, not to replace it with proficiency at issuing instructions.

The long-term asset is a living practice. A method becomes more valuable when it incorporates better judgement and remains useful as its environment changes. The agent is a delivery mechanism for that practice. The author’s continuing curiosity and responsibility are what keep it from becoming a frozen record of what once worked.

Osven is the product we are building around this thesis, by Worksible. Its intended role is to connect expert authorship with business use: a place to define a method, make its scope understandable, apply it with the right context, and bring a person back into the workflow when needed. This paper describes the direction of the product, not a catalogue of capabilities already shipped.

The private beta should begin with narrow assignments and observable standards. We want to understand how much work it takes to encode a useful method, where expert review remains necessary, and what customers need before they trust repeated use. Those questions deserve evidence from real engagements before the model is presented as a general answer to how companies should operate.

We would judge progress through accepted work, repeat use, and the effort required to deliver both. Relevant signals include the share of assignments completed to the agreed standard, the amount of reviewer intervention, the frequency of escalations, and the cost of correcting errors. Customer willingness to return matters more than the number of agents listed in a catalogue.

There are clear ways the thesis could disappoint. Expert methods may prove too dependent on personal context to transfer economically. Review costs may erase the advantage of automation. Customers may prefer general tools or a direct relationship with the expert. Authors may find the maintenance burden greater than the commercial return. These are questions to test, not objections to conceal.

The premise remains ambitious: people should be able to benefit from the repeated application of what they know, and companies should be able to access that knowledge without buying the same hours each time. Making this work requires credible ownership, reliable delivery, and a fair exchange. That is the work ahead. We are inviting the first experts and founders to help determine where it succeeds.