Machine
intelligence,
coordinated

Abstract

Artificial intelligence is becoming a general interface for work. People increasingly describe outcomes instead of procedures; software increasingly decides which tools, data and models should be combined to produce those outcomes. Yet the infrastructure beneath this shift remains fragmented. Model access is gated by isolated providers, compute is provisioned in coarse units, data provenance is difficult to inspect, and the quality of an output is often reduced to a private judgement inside a single application.

LMKJ proposes an AI-native coordination layer that connects intent, compute, evaluation and utility. The protocol does not prescribe one model, one chain or one application category. Instead, it defines a shared language for requesting intelligence and a set of economic and technical primitives for routing that request to the right resources. Agents declare what they need. Providers advertise what they can do. Evaluators contribute evidence about results. Applications settle useful work through a transparent utility signal.

This paper describes the design principles, protocol surfaces, token utility, application pathways, governance approach and risk framework that shape LMKJ. It intentionally focuses on durable use rather than short-term market narratives. The objective is a network where each successful interaction improves the next one, while every participant can understand the role they play.

01 / The context for coordinated intelligence

From isolated models to shared systems

The first generation of AI products made models accessible through a chat window or a single API. That interface was a major step forward, but it also hid the complexity of production intelligence. A useful answer may depend on retrieval, specialized tools, private context, deterministic code, human review and multiple model passes. The application has to orchestrate all of those components, typically with proprietary assumptions and little portability.

As AI moves into research, operations, commerce, robotics and creative work, a new coordination problem emerges. An agent needs to discover a capability without knowing its implementation. A compute provider needs a reliable way to express capacity and constraints. A data steward needs provenance and access rules. A user needs confidence that a result was generated from appropriate sources. These are network problems, not merely interface problems.

The limits of opaque utility

In a closed stack, value is captured at the boundary of the platform. Usage is measured, but contribution is difficult to separate from distribution. A model may be improving because of a dataset, a tool provider or an evaluator, while the system reports only a final response. This makes it difficult to coordinate specialized capacity and difficult for builders to compose services across providers.

LMKJ treats utility as a first-class protocol event. A request, a resource match, an evaluation and a settlement can be represented as distinct but connected steps. This creates a common substrate for applications that need intelligence without requiring every application to reinvent a full marketplace or trust system.

Design principles

• Composable by default. Models, tools, datasets, agents and evaluators are independent surfaces that can be combined.
• Legible over magical. The protocol exposes enough context for participants to understand why a route was chosen and how an output was assessed.
• Utility before speculation. LMKJ is used to coordinate useful work, not to turn every interaction into a financial promise.
• Adaptive, not static. Routes and quality signals improve as the network gathers evidence.
• Human-aligned. Autonomy is paired with permissions, audit trails and clear points of intervention.

02 / Protocol architecture

LMKJ is organized as a modular stack. The modules can be implemented by different teams and deployed across compatible execution environments. The protocol’s role is to define the messages, state transitions and utility relationships that allow those modules to work together.

Intent objects

An intent is more specific than a prompt and less rigid than a conventional transaction. It includes the objective, relevant context, acceptable latency, output constraints and permissions. An application may ask for a research brief with cited sources, a classification with a confidence threshold, or a multi-step workflow that can call external tools. The intent object gives the network enough structure to route the request without forcing the application to know which provider will execute it.

Routing and matching

Routing is a constrained matching problem. The network considers capability, context window, data access, resource fit, latency, geographic or policy requirements and historical evaluation signals. A route can be deterministic for a high-assurance workflow or adaptive for an exploratory one. The important property is that routing decisions can be inspected and improved, rather than remaining a hidden function inside a single product.

Execution receipts

Providers return an execution receipt that links the requested intent to the resources used and the result produced. The receipt does not require revealing private prompts or proprietary weights. It can contain hashes, attestations, timestamps, resource classes and selected provenance metadata. This creates a durable reference for evaluation while respecting application-level privacy.

03 / Agent coordination

Agents are software entities that can interpret intent, select tools, delegate subtasks and return results. In LMKJ, an agent is not defined by a specific model. It is defined by a capability profile and an accountable behavior surface. This allows an agent to upgrade its underlying model without breaking the applications that rely on it.

Capability profiles

A capability profile describes the kinds of work an agent can perform, the context it accepts, the tools it may call and the evidence it can provide. Profiles are discoverable and versioned. An application can choose a profile based on the task rather than coupling itself to a vendor-specific endpoint. Profiles also give evaluators a stable object to score: the agent’s behavior under a defined set of conditions.

Delegation and composition

Complex work often benefits from specialized agents. One agent can retrieve a corpus, another can reason over it, and a third can validate the final output. LMKJ supports this composition through nested intents and delegated receipts. The parent task remains accountable for the requested outcome, while each child task records its own resources and quality signals. Applications can therefore build multi-agent workflows without losing observability.

Permission boundaries

Autonomy without boundaries is difficult to trust. LMKJ agents operate within permission scopes that specify data access, tool access, action limits and escalation conditions. A research agent may read approved sources but cannot publish externally. An operations agent may prepare a transaction but must request approval before execution. Permission changes become visible events, making it easier for users and organizations to audit how an agent was allowed to act.

The goal is not to make agents timid. It is to make their autonomy legible enough that organizations can deploy them in meaningful environments.

04 / The compute mesh

Intelligence depends on resources that vary widely in capability and availability. Training clusters, inference accelerators, edge devices and specialized processors all have different performance profiles. A coordination layer should not flatten those differences into one generic commodity. It should make them addressable.

Resource declarations

Compute providers publish resource declarations that include supported model families, memory classes, throughput ranges, latency expectations, geographic constraints and policy requirements. Providers can update declarations as capacity changes. Applications can request a profile instead of a particular machine, while the route engine selects a suitable provider.

Demand-aware scheduling

Scheduling is shaped by the intent object. A real-time agent may prioritize latency and proximity. A batch research task may prioritize throughput and evaluation history. A creative workflow may require a specific model family or a private environment. By expressing those constraints directly, the network can direct demand to the resources that are most useful for the job.

Attestation and provenance

Where available, providers can attach hardware or environment attestations. These signals do not establish that an output is correct, but they can establish that an execution occurred in a declared environment. Provenance records can link a result to a dataset version, tool call or model version. Together, these mechanisms help applications distinguish an answer that is merely plausible from one that is supported by an auditable path.

Efficient resource use

Efficient routing is an economic and environmental concern. LMKJ encourages caching, model selection, batching and reuse when those strategies preserve the requested quality. A route can prefer a smaller model for a simple task, reserve a larger model for difficult reasoning and use evaluators to determine whether the trade-off was appropriate. The protocol’s utility signal therefore rewards useful outcomes, not raw compute consumption.

05 / LMKJ utility model

LMKJ is the native coordination signal for the network. Its role is to represent access, contribution and accountability across the protocol. Utility is expressed through events that correspond to work being requested, supplied, evaluated or composed.

Request utility

Applications use LMKJ to express demand for compute, agent services, data access and evaluation. A request can be direct, where an application chooses a provider, or routed, where the network selects resources based on the intent. The utility event records the task class and the contributors involved without requiring an application to expose private business logic.

Contribution utility

Providers, data stewards and evaluators contribute resources that make a completed task possible. The utility model recognizes these roles separately so that specialized capacity can develop. A high-quality dataset is not the same contribution as a fast inference endpoint, and a careful evaluator is not the same as either. Separating roles helps the ecosystem coordinate around real capabilities.

Consumption loop

When a task completes, the protocol closes a consumption loop. The application receives a result, the route is recorded, the evaluation signal is attached and the utility event is settled among the relevant contributors. Repeated use creates a growing body of evidence about which routes, providers and agent profiles are effective for different classes of work.

Utility controls

• Rate limits and policy gates can prevent automated abuse.
• Applications can set approval thresholds for high-impact tasks.
• Evaluators can be rotated or challenged when signals diverge.
• Providers can pause capacity without invalidating historical receipts.
• Governance can update schemas while preserving version history.

06 / Robot operator model

LMKJ treats a robot operator as a coordinated service rather than a single machine. An operator can be a fleet controller, a compute cluster, a sensor gateway, or an autonomous unit with a narrow capability. What matters is that the operator publishes a profile, accepts a bounded task, returns evidence, and participates in a visible utility event.

Capacity commitment

Operators can commit a defined capacity envelope to the network. The envelope describes the task classes they accept, the environments they can reach, the response conditions they support, and the proof signals they can provide. A warehouse fleet may commit inventory scans, an aerial fleet may commit terrain mapping, and a compute operator may commit inference for a specific model family. Capacity is declared as a service boundary, not as an invitation to hide operational constraints.

Proof-of-work for machines

Robot mining in LMKJ refers to useful machine work that can be measured, evaluated, and referenced by later tasks. A robot does not mine by burning energy to solve an arbitrary puzzle. It mines by completing a declared objective: collecting a sensor pass, moving an approved payload, labeling an environment, running an inference batch, or validating another operator's output. The network records the task receipt, the evidence used, and the evaluation path so that contribution can be understood.

Activation and staking

Operators may activate participation by committing LMKJ to an operating role. This commitment signals that the operator is available for a defined class of work and is willing to follow the network's permission, quality, and reporting rules. The model is designed around active participation: an operator that remains available, returns consistent evidence, and responds to challenge paths becomes more useful to the mesh. The protocol does not treat passive holding as machine contribution.

Reward routing

When a task is completed, the utility event can route recognition across the operator, the application, the evaluator, and any supporting data or compute service. The exact composition depends on the task policy. A high-assurance workflow may direct more weight toward validation; an exploration workflow may emphasize responsiveness and coverage. The key principle is that machine operators are recognized for useful, verifiable work rather than for abstract network presence.

Operator safeguards

• Every operator has a permission envelope that can be narrowed or revoked.
• Task receipts can omit private payloads while preserving hashes and provenance.
• Evaluators can challenge incomplete, unsafe, or inconsistent results.
• Applications can require human approval before an external action.
• Operators can pause capacity without rewriting historical receipts.

07 / Evaluation and quality

Quality is contextual. A useful answer in a creative workflow may not be the right answer in a compliance workflow. LMKJ therefore treats evaluation as a set of signals rather than one universal score. Applications can declare which dimensions matter for a task, and evaluators can provide evidence against those dimensions.

Evaluation dimensions

Common dimensions include relevance to the intent, factual support, provenance completeness, policy compliance, latency, resource efficiency and user-defined acceptance. A task can require a minimum combination of signals or ask an application to review the result when signals conflict.

Independent evaluation

Evaluators operate independently from the provider that generated an output. They may use reference data, deterministic checks, another model, human review or a combination of methods. Each evaluation includes a method declaration so that downstream users understand what kind of evidence they are reading. Evaluators can specialize by domain, allowing medical, legal, scientific and creative applications to establish distinct quality practices.

Feedback and improvement

Evaluation is useful only when it changes future behavior. Routing can use aggregated signals to prefer providers and agent profiles that perform well for a given task class. Applications can also maintain their own acceptance policies. The network does not erase disagreement; it makes disagreement visible and gives builders the tools to respond.

Challenge paths

When a result is disputed, the task can enter a challenge path. A second evaluator or a human reviewer examines the receipt and the original criteria. The challenge outcome becomes part of the historical signal. This creates a practical way to improve the system without pretending that every automated judgement is final.

08 / Application ecosystem

LMKJ is designed to serve applications that need intelligence to move across boundaries. The first ecosystem surfaces are intentionally broad so that builders can discover where coordination produces the most leverage.

Research and knowledge

Research agents can search approved corpora, compare evidence, generate structured briefs and preserve citations. The protocol can coordinate retrieval, synthesis and review as separate tasks, giving a research team a clear path from source to conclusion.

Operations and automation

Operational agents can monitor workflows, prepare actions and request approvals. Permission scopes and execution receipts make it possible to automate repetitive work while maintaining a record of what the agent saw, decided and attempted.

Creative production

Creative teams can compose specialized agents for ideation, editing, localization, asset analysis and quality review. Each capability can be provided by a different service while the application keeps one coordinated workflow.

Data and simulation

Data stewards can make curated collections discoverable with provenance and access policies. Simulation providers can offer scenario engines for planning, testing and research. Agents can combine these resources as part of a single intent instead of integrating every provider separately.

Developer distribution

Builders can use LMKJ SDKs to publish an agent profile, expose a tool, register a dataset or become an evaluator. Templates standardize common patterns while leaving room for product-specific interfaces. The best ecosystem is not one that forces every application into the same shape; it is one that makes useful capabilities easy to find and compose.

09 / Governance and participation

Governance is responsible for the rules that keep coordination useful as the network grows. It should be conservative around core schemas, transparent about changes and open to the people who build, operate and evaluate the system.

Protocol stewardship

Stewardship begins with clear versioning. Schema changes, evaluator standards and permission primitives are proposed with rationale, implementation notes and migration guidance. Historical receipts remain interpretable through version identifiers, preventing silent changes to the meaning of past work.

Working groups

Specialized working groups can focus on model interoperability, compute operations, data provenance, application safety and developer experience. Working groups publish their decisions and open questions. This structure lets domain experts contribute without requiring every participant to understand every layer.

Signal-based participation

Participation is grounded in contribution. Providers demonstrate reliability through execution history, evaluators through the quality of their assessments and builders through applications that create useful demand. Governance can consider these signals while avoiding a single reputation number that would be easy to game or difficult to interpret.

Human oversight

Critical changes retain a human review path. Automated proposals can surface patterns and recommend updates, but final decisions around permissions, evaluator standards and protocol safety should remain accountable to identifiable stewards and documented processes.

10 / Risk framework

AI coordination introduces technical, operational and social risks. A credible protocol makes those risks explicit and gives applications practical controls rather than hiding them behind an optimistic narrative.

Model risk

Models can hallucinate, fail under distribution shift or reproduce harmful patterns. LMKJ mitigates these risks through task-specific evaluation, provenance, model versioning and application-level acceptance policies. No protocol can guarantee correctness; it can make the conditions of an output easier to inspect.

Data and privacy risk

Intent objects may contain sensitive context. Applications should minimize what they reveal, use permissioned data providers and apply encryption or secure execution where appropriate. Receipts can record hashes and selected metadata instead of private content. LMKJ provides coordination primitives, not a substitute for an application’s privacy program.

Provider and availability risk

Providers can fail, throttle capacity or change their policies. Multi-provider routing, fallback profiles and explicit service constraints help applications maintain continuity. Historical receipts make it possible to understand whether a failure was isolated or systemic.

Automation and misuse

Autonomous systems can be used to spam, manipulate evaluation or perform actions beyond their intended scope. Rate limits, permission boundaries, challenge paths and human approval thresholds are core safety surfaces. Builders should treat the ability to pause or revoke an agent as a product requirement.

Governance risk

Coordination can become centralized if a small group controls schemas, evaluators or access. Open documentation, versioned proposals and diverse working groups reduce this risk. The protocol should favor inspectable rules over private exceptions.

11 / Roadmap

LMKJ develops in capability phases. Each phase is defined by a new form of coordination that can be tested by builders and evaluated by the ecosystem.

Foundation

The foundation phase establishes intent schemas, capability profiles, execution receipts and the first evaluation interfaces. The focus is interoperability: a small set of primitives that different applications can implement without rewriting their product logic.

Network

The network phase expands the provider surface. Compute operators, data stewards and evaluators can publish profiles, expose capacity and establish domain-specific quality methods. Routing begins to use historical evidence while preserving application control.

Composition

The composition phase introduces multi-agent workflows, delegated intents, builder SDKs and reusable templates. Developers can assemble specialized intelligence without building every service from scratch.

Autonomy

The autonomy phase focuses on adaptive routing and self-improving coordination. The network can learn which combinations of models, tools, data and evaluators work best for a task class while keeping the ability for applications and humans to override decisions.

Closing perspective

AI will not be defined by one model or one interface. It will be defined by the systems that let intelligence move through the world responsibly. LMKJ is a proposal for that system: a shared coordination layer where demand is structured, capability is discoverable, quality is inspectable and useful work can compound over time.

The long-term opportunity is not to make intelligence louder. It is to make it more available to the people and applications that can use it well.

12 / Implementation patterns

A protocol becomes valuable when it can fit into real products without requiring teams to abandon their existing architecture. LMKJ is therefore designed as a set of implementation patterns rather than a single prescribed application. A builder can start with one surface, validate a use case and expand as the product requires deeper coordination.

Application gateway

The simplest integration is an application gateway. A product sends a structured intent to a gateway that handles provider discovery, routing and receipt construction. The application retains its own user experience, data policy and acceptance rules. The gateway can begin with a small set of trusted providers and gradually add evaluation and fallback paths as demand grows.

This pattern is useful for teams that want to introduce agent capabilities without exposing their internal orchestration. The gateway creates a boundary between the product and the wider intelligence field. It can normalize provider APIs, protect private context and convert product-specific events into protocol-compatible records.

Provider adapter

Existing model, compute or data providers can participate through an adapter. The adapter translates a provider’s capability declaration into a profile that the network understands. It can expose supported workloads, resource limits, privacy constraints, evaluation methods and operational status. The provider remains in control of its infrastructure and can decide which intent classes it will accept.

Adapters are important for ecosystem breadth. They allow teams with strong infrastructure to participate without rewriting their control plane, while giving applications a consistent way to compare capabilities. Over time, shared adapter libraries can reduce integration work and make specialized services more discoverable.

Evaluator service

An evaluator service receives a result and the criteria associated with the original intent. It may run deterministic checks, compare against references, call a second model, ask a human reviewer or combine several methods. The service returns a structured signal with an explanation of its method and confidence. Applications can choose evaluators based on domain, latency and policy.

Evaluator services create room for independent quality businesses. A scientific evaluator might validate citations and numerical consistency. A creative evaluator might inspect adherence to a brief. An operational evaluator might test whether an action produced the requested state. The protocol keeps these methods separate so that quality remains contextual rather than being reduced to one platform score.

Agent operating surface

More advanced builders can implement a complete agent operating surface. This includes profile publication, nested delegation, tool permissions, execution receipts and local policy decisions. The agent can choose when to ask for help, which specialist to delegate to and when to escalate to a human. LMKJ provides the coordination vocabulary while the application retains responsibility for its domain behavior.

Progressive adoption

These patterns support progressive adoption. A team can start with routing, add receipts when auditability becomes important, introduce independent evaluation for quality-sensitive workflows and only then expose a broader market surface. This sequencing reduces integration risk and lets the ecosystem learn from real usage instead of assuming that every capability is needed on day one.

13 / Participation and network behavior

The strength of an intelligence network is determined by the quality of its participants and the clarity of the relationships between them. LMKJ distinguishes participation roles so that incentives and responsibilities remain understandable as the system expands.

Builders

Builders create applications that turn coordinated intelligence into user value. They define intents, set acceptance policies, select the evidence they need and decide where a human should remain in the loop. Builders also create the demand that gives providers a reason to publish capabilities. A healthy network should make it easier for builders to test a new service than to build every service themselves.

Compute and model providers

Providers supply execution capacity, models and specialized tooling. Their role is not only to return an output, but also to declare enough context for an application to make a responsible selection. Providers that serve difficult workloads can differentiate through quality history, latency consistency, privacy controls and domain-specific attestations.

Data contributors

Data contributors make curated information available with provenance and policy. They can publish datasets, retrieval indexes, labels, evaluation sets and temporal updates. A dataset is a living resource: its version, coverage and limitations matter. LMKJ gives data contributors a way to express those details as part of a capability profile rather than burying them in a private sales process.

Evaluators

Evaluators add independent evidence. Their contribution is especially important as applications move from conversational prototypes into high-consequence workflows. Evaluators should be able to explain their methods, identify the boundaries of their tests and revise their methodology when evidence shows that a signal is incomplete.

Users and organizations

Users and organizations set the outcomes that make the network meaningful. They define what good work looks like, which data can be used and what actions require approval. Their feedback can be captured as acceptance signals while preserving the privacy of the underlying interaction. An organization may value traceability over speed for one workflow and speed over depth for another; the protocol should support both without forcing a universal preference.

What healthy behavior looks like

A healthy network has visible specialization. Providers publish clear profiles instead of vague promises. Applications provide specific intents instead of sending unstructured demand into an opaque queue. Evaluators explain their methods instead of issuing unexplained rankings. Governance responds to evidence instead of optimizing for attention. These behaviors create a compounding loop: better descriptions improve routing, better routing creates better outputs, better outputs create better evaluation data and better data makes the next route more reliable.

Durable coordination

Durable coordination requires patience. Some of the most important protocol improvements will look small from the outside: a clearer schema, a better receipt, a more honest evaluator profile or a safer permission boundary. Those details determine whether applications can trust the network when the novelty of AI has faded. LMKJ is designed to accumulate these details into a practical substrate for intelligent work.

The network’s long-term identity should be defined by the quality of the work it helps people complete. Utility is the visible outcome; coordination is the underlying advantage.

14 / Measurement and observability

Coordination only improves when the system can see what happened. LMKJ treats observability as a protocol capability: every meaningful step should produce enough structured context to support debugging, evaluation and governance without forcing participants to reveal private content.

Operational signals

Applications can monitor route latency, completion rate, retry frequency, evaluator disagreement and policy escalations. Providers can monitor capacity, model version behavior and failure classes. These signals help teams distinguish a bad prompt from a degraded provider, a missing dataset from a routing error or a policy conflict from a transient outage.

Outcome signals

Outcome signals describe whether the requested work was useful. They can include acceptance, revision, citation coverage, task completion, human override and downstream impact. The protocol does not require one universal metric. Instead, it gives applications a way to attach the measures that correspond to their domain and compare them across versions.

Privacy-aware telemetry

Telemetry should be minimized. Receipts can use hashes, categories and aggregate ranges rather than storing the private body of an intent. Applications decide which details remain local and which signals are safe to share. This balance lets the network learn from behavior while respecting the boundaries that make enterprise and personal use possible.

Evidence for decisions

Over time, observability creates an evidence layer for routing and governance. A proposal to change an evaluator standard can reference the failure class it is meant to address. A provider can demonstrate a reliability improvement through its execution history. An application can choose a route based on the evidence that matters to its users. This is how a network becomes more intelligent without making intelligence itself opaque.