Cognitive Microengines: From Instructions to Executable Capabilities

From Expanding Instructions to Bounded Executable Capabilities

An architecture white paper, implementation report and research agenda
Nordlith Research · 26 October 2026 · Version 1.0
Research classification: engineering design and first-party implementation case study. Not peer reviewed.

Executive summary

AI assistants often become more capable by accumulating instructions: how to select tools, preserve permissions, verify outcomes, retain context and respond to failures. Yet every additional procedure can impose retrieval, interpretation and coordination costs. The agent may repeatedly spend expensive general reasoning on work whose mechanics are stable. The resulting harness can improve correctness while becoming slower, harder to maintain and less economical.

Cognitive Microengines (CME) emerged from a sustained human–AI design collaboration addressing that tension. The originating human proposal was to replace repeated loading and interpretation of instruction sets with small executable engines. A subsequent refinement made the idea more than conventional automation: some engines should contain narrowly bounded model reasoning, rather than being exclusively mechanical.

A Cognitive Microengine is a versioned, task-scoped executable capability with an explicit contract, deterministic admission and validation, optional bounded model reasoning, an evidence-bearing result, and a defined route back to the parent when uncertainty exceeds its remit. The parent retains task meaning, authority and final semantic acceptance. An engine is not an independent source of permission.

This paper describes three modes—mechanical, cognitive and hybrid—and a reference implementation with typed requests, bounded execution, trusted registration, read-only compositions, migration controls and rollback. It reports two small first-party pilots. Both suggest useful task-level improvements, but neither establishes universal performance, financial payback or superiority to other frameworks. One pilot also increased total model-related calls despite lower measured latency and input use. That negative result matters: moving instructions into engines can merely relocate overhead unless the entire accepted task is measured.

The contribution is an implemented engineering synthesis and a testable operating discipline, not a claim to have invented modular software, model routing, agents-as-tools or compound AI systems. The central proposition is narrower: repeated harness procedures can become governed executable capabilities without transferring broad intent or authority away from the parent. Whether this produces durable gains must be established per task, including development, discovery, validation, exceptions and maintenance.

1. Origin: the problem that prompted CME

The design began with an operational observation. A capable assistant acquires procedures because previous failures reveal missing controls. More instructions can prevent repeated mistakes, but the assistant must then find, load, interpret and apply those instructions during future work. Even when the rule is stable, its execution may remain a fresh reasoning exercise.

The originating design question was whether an AI harness could acquire small callable engines in the same practical spirit that it acquires tools, rather than continually expanding the instructions that the parent must interpret. The human collaborator then explicitly extended the proposal to include limited reasoning through an appropriately selected model. The intended object was not simply a script and not simply another autonomous agent. It was a bounded capability that could perform a defined piece of work and return a usable result.

The retained development record dates this proposal and its initial research to October 2026. Subsequent implementation records document an opt-in toolkit, native mechanical interfaces and limited measured adoption. This provenance establishes the origin of this particular development programme. It does not establish that the underlying architectural ideas were absent from prior work, nor does this paper make a legal inventorship, patentability or naming-exclusivity claim. [I1–I4]

CME should therefore be understood as a co-developed response to a specific systems problem: how can an assistant gain reliable capability without making every future interaction carry the full cost of its procedural history?

2. Research question and contribution

The research question is:

Can repeatable instruction-driven harness work be converted into bounded executable capabilities that reduce the cost of reaching an accepted outcome while preserving intent, authority, exception handling and evidence quality?

The programme contributes four connected elements:

1. A capability abstraction spanning deterministic functions and narrowly model-backed judgment.
2. A contract and receipt discipline that distinguishes mechanical verification, model candidates, explicit uncertainty and parent acceptance.
3. A controlled adoption lifecycle binding original procedures to tested replacements, source versions and reversible activation.
4. Preliminary measurements that expose both local improvements and the substantial cost of coordination.

No element alone establishes a new field. The proposed value lies in their integration around the maintenance and execution of an agent harness. A future comparative evaluation could find that an existing framework implements the same discipline more efficiently. That would not invalidate the operational problem; it would change the preferred implementation.

3. Relationship to existing work

3.1 Compound AI systems

The compound-systems perspective describes applications built from interacting models, retrieval, tools and ordinary software, rather than a single monolithic model. CME sits within that established perspective. It selects a narrower unit of design: a repeatable harness capability with a bounded interface and an adoption history. It does not claim that combining models and software is new. [1]

3.2 DSPy and programmable language-model modules

DSPy treats language-model pipelines as programs composed from declarative modules and optimizes their invocation strategies against a metric. It is close prior art for moving beyond brittle, manually maintained prompt strings. CME's emphasis in the implementation described here is different: source-bound procedural replacement, operational limits, explicit uncertainty and retention of parent authority. This is a difference in emphasis and contract, not evidence that DSPy cannot support equivalent safeguards. CME does not implement a general automatic prompt optimizer or claim compilation equivalence for arbitrary natural-language policies. [2]

3.3 Composable workflows and agents-as-tools

Anthropic's engineering guidance distinguishes predefined workflows from agents that dynamically control their process, recommending the simplest adequate approach. The OpenAI Agents SDK documents agents exposed as callable tools without a full handoff. These are direct precedents for a parent delegating a narrow operation while retaining overall control. A CME can be implemented using such patterns; it need not introduce another transport or agent framework. [3,4]

3.4 Model routing

RouteLLM studies learned routing between stronger and weaker models to manage a cost–quality trade-off. CME is not synonymous with routing. A mechanical engine uses no model; a model-backed engine still needs an input boundary, permitted decision space, verification and uncertainty policy after a model is selected. Routing is one possible implementation choice inside that broader capability contract. Published routing results must not be imported as evidence that CME itself achieves equivalent savings. [5]

3.5 What this paper does and does not establish

This is a targeted related-work comparison, not an exhaustive novelty survey. It supports describing CME as a concrete engineering synthesis within an established landscape. It does not support claiming that bounded model-backed functions, heterogeneous inference or governed composition originated here.

4. The CME abstraction

A microengine has a stable purpose and a deliberately limited decision surface. Its contract should state:

• Identity, version, owner and source provenance.
• Trigger and counter-trigger: when to use it and when not to.
• Accepted inputs, allowed outputs and relevant semantic constraints.
• Permitted effects and applicable authority boundaries.
• Model policy, if any, and the actual provider identity when used.
• Input/output, call, retry and time budgets.
• Verification rules, uncertainty conditions and escalation behaviour.
• Lifecycle state and the evidence required for adoption or rollback.

The reference implementation separates three modes. [I2]

Mode	Operation	Model use	Meaning of a successful result
Mechanical	Trusted deterministic computation or consistency checking	None	The specified mechanical check completed on the supplied data
Cognitive	A tightly scoped judgment through an explicit adapter	Bounded	A model candidate was returned; semantic truth is not guaranteed
Hybrid	Deterministic admission, bounded judgment, deterministic validation	Bounded	Contract and result checks passed; broader semantic acceptance remains separate

An engine can share a model service with other engines. The word microengine describes the bounded capability, not a requirement to host separate weights or run a separate server. Small parameter count, low price and low end-to-end latency are different properties and must be measured rather than conflated.

A concise architecture is:

Authenticated task and current authority
                 |
        Parent selects bounded work
                 |
       Contract and source admission
                 |
   Mechanical handler OR explicit model adapter
                 |
     Deterministic result checks and receipt
                 |
 Verified mechanical result / candidate / abstention / error
                 |
       Parent interpretation and acceptance

The return path is essential. If an engine cannot support a conclusion within its contract, the correct result may be abstention. Forcing a choice to make the workflow appear productive defeats the abstraction.

5. What has been implemented

The reference toolkit is local, opt-in and callable through Python and JSON-oriented interfaces. The original builtin catalogue exposes numeric summation, JSON primitive-contract checking, shortlist-based tool-fit judgment and a verified tool-fit hybrid. A later native catalogue also advertises budget-window, artifact-scope and acceptance-coverage consistency checks, a joint implementation audit, and named source/receipt audit compositions. Listing a cognitive engine is not permission to run it through every interface. The installed native surface remains restricted to its admitted mechanical/provided-data operations; model-backed execution requires the explicit supported adapter path. [I2–I4]

The runtime records engine identity and version, status, structured output, evidence and uncertainties, elapsed time and model-call accounting. When a model is used, provider provenance and whether fallback occurred are separate fields. Unavailable or rejected work is not converted into a fabricated successful receipt.

The initial manifest contract constrains effects to none, forbids fallback, and gives mechanical handlers a zero-model-call budget. Cognitive and hybrid handlers use explicitly supplied adapters under bounded-call policies. The contract language deliberately covers a small set of primitive input/output checks; it is not a substitute for a complete general-purpose schema or deep semantic validation. [I2]

The implementation also includes source-bound registration and a migration workpad. An engine is not executable merely because a model or request supplies a path or declares a manifest. Trusted code is registered through the maintained implementation. Adoption binds the source being replaced to the target engine and its evidence; source drift invalidates that binding.

These are implemented capabilities, but their acceptance records do not imply that the whole assistant has been automatically converted to CME. Broad prompt compilation, wholesale instruction replacement and universal background routing are not established outcomes of this work.

6. Authority, evidence and uncertainty

6.1 A result cannot grant permission

A microengine can evaluate supplied conditions; it cannot authenticate its own right to act. A source document, model response or request field saying that an action is approved does not create approval. The parent must bind the authenticated request to the applicable authority before consequential work.

This is why the published read-only checks are useful but intentionally modest. A source audit can check the consistency of supplied bytes and a digest. It does not establish that those bytes came from an authoritative production system. An acceptance-coverage check can inspect a supplied coverage representation. It cannot establish that the claimed external outcome occurred.

6.2 Verified structure is not verified meaning

An output can contain valid JSON, a permitted identifier and all required fields while still recommending the wrong action. The hybrid label means that specified deterministic validations passed. It is not a declaration that all important semantics have been proved. A receiving agent must preserve that distinction rather than upgrading every green receipt into truth.

6.3 Bounds are not sandboxing

Trusted Python handlers execute in the local process and are not isolated by an operating-system security sandbox. A declared no-effects policy and counters do not prove that arbitrary malicious code could not perform effects. Source review and trusted registration remain necessary.

Timeouts also need precise interpretation. A local deadline may prevent late output from being accepted while a thread or previously submitted remote inference continues. Rejected late output is not proof of remote cancellation. Call budgets are not billing guarantees. The implementation documentation explicitly retains these limits. [I2]

6.4 Composition must preserve the boundary

Named audit compositions combine existing checks under shared byte, call and deadline budgets. They accept provided data, not arbitrary executable pipeline definitions from an untrusted caller. A sequence of individually valid checks can still fail as a whole if it exceeds aggregate limits, loses uncertainty or crosses an authority boundary. The reference design therefore treats the aggregate receipt and shared budget as first-class objects, rather than assuming that local success composes automatically.

7. Adoption: turning instructions into a capability

The useful unit of adoption is a specific recurring procedure, not a vague instruction to make the assistant more efficient. A practical lifecycle is:

1. Identify the original procedure, its owner, exceptions and current source version.
2. Classify which parts are deterministic, which require narrow judgment and which must remain with the parent.
3. Define the smallest adequate contract and collect representative failure cases.
4. Implement and test the candidate without changing the live route.
5. Compare the original and candidate on matched tasks, including ambiguous and adversarial inputs.
6. Obtain the appropriate independent scrutiny and owner decision for that replacement.
7. Activate a specific route reversibly, retaining source and rollback evidence.
8. Measure actual accepted-task performance and retire the replacement if its net value is poor.

The source link matters because a supposedly equivalent engine can drift while its description remains unchanged. Rollback matters because a faster happy path can conceal costly exceptions. Neither requires a new framework for every replacement: existing functions, tools and maintained registries should be reused where they already provide the needed mechanics.

An adopted engine must also be discoverable. A perfectly implemented module that future sessions cannot find is not an operational efficiency gain. The maintained caller, compact skill description, invocation and verification record are part of the capability, not optional documentation afterthoughts.

8. Preliminary implementation evidence

8.1 Evidence provenance and method

The following measurements come from retained first-party engineering records, not an independent benchmark campaign. This paper inspected source-bound design and acceptance records, the stored pilot results and the current catalogue. It did not rerun the historical pilots, reproduce their model environments or commission a new benchmark.

The native catalogue was queried during preparation to check the exposed capability inventory. That observation is distinct from exercising every engine or establishing the current health of every adapter. The historical test and rollback figures below describe their recorded release events, not a new reproduction performed for this paper. [I3,I4]

8.2 Pilot A: explicit procedure versus compact engine-assisted procedure

The first pilot compared three matched tasks: budget, scope and evidence coverage. Each arm had one observation per task. The baseline supplied the fuller original procedure; the candidate used compact instructions and the installed mechanical checks. Both arms produced three accepted answers in their observed cases.

Measure	Baseline	Candidate
Observations per arm	3	3
Correct answers in the recorded sample	3	3
Mean task time	29.42 seconds	19.08 seconds
Input tokens excluding recorded cache reads	93,499	65,111
Input including recorded cache reads	301,371	274,647
Recorded API calls across the included tasks	13	15

The stored comparison reports 35.13% lower total/mean task time and 8.87% lower input including cache. Those figures must be read alongside the increased call count. Four baseline computation attempts were denied by tool guards and required recovery; that friction is included in the comparison. The pilot therefore measures the tested procedures in that environment, not the isolated speed of an engine. Cache warmth and execution order were not fully controlled. [I3]

8.3 Pilot B: combining three existing checks

A later pilot compared separate native checks with a joint implementation-audit route. Again, there were three matched cases and one observation per case per arm. Both arms produced three verified answers.

Measure	Separate checks	Joint audit
Observations per arm	3	3
Correct answers in the recorded sample	3	3
Mean task time	25.81 seconds	20.36 seconds
Input including recorded cache reads	275,800	266,890
Engine-run calls	9	3
Recorded primary-model calls	15	15

The stored reduction in mean time is 21.14%, while input including cache fell 3.23%. Engine-run calls fell, but primary-model calls did not. The associated release record reports 104 regression tests, a 27-case private status matrix and exercised code/guidance rollback. Those are implementation-verification results, not independent evidence that the latency effect generalizes. [I4]

8.4 The result that prevents a victory lap

The composition acceptance record explicitly states that parent coordination remained expensive and that no whole-delivery cost or financial payback win was demonstrated. Its accounting includes substantial parent activity and also identifies exclusions at the measurement boundary.

That result is central to the research argument. It is possible to make a microengine call cheaper while making the surrounding project more expensive. The pilots motivate further evaluation; they do not establish statistical significance, a population-level accuracy guarantee, monetary savings or superiority to other systems. The two percentage improvements must not be added together, and successful cases in such a small sample cannot certify that rare failures are absent.

9. A worked example: selecting a capability without handing over the mission

Consider an assistant choosing between a small set of candidate tools for an authenticated task. The example is conceptual; it is not an additional measured experiment.

The parent supplies a concise task description and an explicit shortlist. Deterministic admission checks the shape of the request and the allowed candidate space. A bounded cognitive step may recommend one listed identifier or return uncertainty. A hybrid validator rejects an identifier outside the shortlist and checks the required result fields.

The engine must not browse the entire conversation history, select another user's profile, create new permissions or silently choose an unapproved provider. Descriptions inside the shortlist are data, not instructions that can rewrite the engine's contract. An apparently relevant recommendation still returns to the parent for acceptance in the broader task context.

Three outcomes are useful:

• A supported candidate is returned with its permitted evidentiary status.
• Ambiguity produces abstention and the unresolved question.
• Invalid, stale or out-of-scope input produces a bounded error before unnecessary model contact.

This arrangement can save repeated procedural reasoning when the task is genuinely narrow. It is a poor fit when the real difficulty is deciding the owner's objective or interpreting a new authority boundary. Encapsulating such ambiguity in a tiny interface does not make it safe or cheap.

10. Evaluating CME properly

A stronger evaluation should compare direct parent handling, on-demand prose guidance and a CME implementation using the same task distribution and acceptance standard. Where appropriate, a conventional function/tool and an established framework should also be included. The baseline must not be artificially weakened by a deliberately verbose prompt or avoidable environment mismatch.

The unit of measurement should be the accepted task. Capture discovery and routing, cold and warm startup, queueing, model use, parsing, validation, retries, abstention, human/parent interpretation and requester intervention. Report the full delivery and maintenance effort separately from recurring invocation cost. A method only pays back its implementation cost if the recurring benefit exceeds its ongoing overhead over the actual reuse horizon.

Useful outcome measures include:

• Task correctness and evidence sufficiency under a prespecified rubric.
• Unsafe acceptance, false refusal and missing-exception rates.
• Appropriate abstention and escalation under uncertainty.
• Time to accepted result, including tail latency.
• Input/output usage, cache treatment, all relevant model calls and real invoiced costs where available.
• Development, review, integration and maintenance effort.
• Recovery cost when an engine becomes stale or unavailable.

The test set should contain straightforward tasks, ambiguous inputs, conflicting supplied claims, malformed structures, stale source versions, provider outages, large outputs and invalid authority assertions. Repeated trials and counterbalanced execution should separate environment noise from a real treatment effect. The appropriate sample size and statistical analysis depend on the task distribution; this paper does not prescribe an unsupported universal number.

A particularly important ablation is verification cost. If the parent must reperform the entire delegated task to trust the result, the capability may be useful for consistency but not economical. That trade-off should be reported rather than hidden behind a low inference-time figure.

11. Limitations and open questions

First-party evidence. The authors designed the system and interpret its internal records. Independent reproduction and externally accessible evaluation artifacts are needed before strong comparative claims.

Small, selected samples. The pilots concern a few operational consistency tasks. They do not represent long-horizon agency, open-ended reasoning, sensitive decision-making or broad model quality.

Restricted effect model. The described published checks are read-only/provided-data operations. Extending CME to consequential writes would require separate authentication, authorization, idempotency, external-state verification and recovery controls. The read-only results do not validate that extension.

Semantic preservation. Moving instructions into code can omit qualifications that were visible in prose. Equivalence is task-specific, and a correct schema cannot establish that all relevant meaning survived.

No security sandbox claim. Trusted registration, counters and local deadlines do not isolate arbitrary Python or guarantee cancellation of distributed work.

Measurement boundaries. Cache behaviour, guard friction, parent activity and accounting exclusions affect the observed results. Token counts are not invoices. The report does not establish net financial return.

Novelty and access. The related-work review is targeted rather than exhaustive. The name CME is descriptive working terminology, not a demonstrated exclusive brand. Implementation and benchmark records are not all public; the public reader cannot independently verify every internal claim from this manuscript alone.

Automation debt. As the engine catalogue grows, discoverability, overlapping responsibilities, stale source pins and maintenance become research problems themselves. More microengines are not automatically better.

12. Implications for researchers and agent designers

For researchers, CME offers a concrete object for studying the boundary between general reasoning and repeatable operational execution. The strongest experiment is not simply whether a small model can replace a large one. It is whether a constrained capability can lower the total cost of accepted work while preserving essential behaviour across normal cases and failures.

For agent designers, the practical recommendation is to begin with stable, frequently repeated, reversible work whose verification is inexpensive. Keep rich context and authority interpretation with the parent. Use deterministic code for deterministic requirements; introduce model reasoning only where it materially helps. Make uncertainty a valid result, and preserve a maintained entrypoint so the capability can actually be reused.

For agents consuming an engine's output, preserve the receipt's status. A mechanically verified consistency result is not an authorization. A cognitive candidate is not a fact. A timeout is not cancellation. A source digest is not source authority. These distinctions make composability more credible than a generic success flag.

13. Conclusion

Cognitive Microengines arose from a practical human–AI invention process: a human identified the cost of continually expanding an assistant's instructions, then proposed small engines that could include bounded reasoning; the collaboration developed that idea into an implemented capability model and adoption discipline.

The resulting system demonstrates mechanical, cognitive and hybrid abstractions, source-bound contracts, uncertainty-aware results and reversible adoption. Early first-party pilots show promising local improvements alongside unchanged or increased call counts and substantial coordination costs. That combination argues for careful iteration rather than inflated claims.

The durable idea is not that every instruction should become an engine. It is that stable procedural work should have an executable, governed home when doing so improves the complete task. The test of CME is therefore operational: less repeated interpretation, preserved human intent, and lower cost to reach an outcome that can actually be accepted.

References

[1] Zaharia, M., and collaborators. The Shift from Models to Compound AI Systems. Berkeley Artificial Intelligence Research, 2024. Primary source.

[2] Khattab, O., and collaborators. DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. 2023 preprint. Paper.

[3] Anthropic. Building Effective Agents. Engineering guidance originally published in 2024; retrieved 26 October 2026. The current page notes subsequent tooling changes. Primary source.

[4] OpenAI. Agents SDK: Tools, including agents-as-tools and structured tool input. Living documentation, retrieved 26 October 2026. Primary source.

[5] Ong, I., and collaborators. RouteLLM: Learning to Route LLMs with Preference Data. Paper, version 4.

[I1] Retained human–AI development conversation and initial CME research proposal, 10 October 2026. Internal provenance, inspected for this paper. Private conversation content is not reproduced.

[I2] CME implementation brief and engine contract. First-party maintained design/implementation documentation, inspected 26 October 2026. Records distinguish original requirements, installed behaviour and later additions.

[I3] CME expansion pilot: verified measurements and limitation notes, 18 October 2026. Three matched cases, one observation per arm. Internal first-party evidence; no independent replication claimed.

[I4] CME composition release acceptance and verified measurement records, 18 October 2026; current builtin/native catalogue observations, 26 October 2026. Historical release verification and current catalogue discovery are different evidence surfaces.

Provenance and disclosure

This paper records a design developed through collaboration between the originating human operator and TARS, an AI assistant. The human contribution included the initial problem formulation and the explicit proposal for small reasoning-capable engines. TARS contributed research synthesis, architecture elaboration and implementation/verification coordination. This account is collaborative engineering provenance, not a legal determination of authorship or inventorship.

The manuscript was produced with AI assistance and checked against retained first-party records and the cited external sources. It has not undergone external peer review. No new performance benchmark was conducted for this paper. Public-facing prose excludes personal names, credentials, internal infrastructure details and raw private correspondence. Internal evidence references are retained for audit but are not represented as publicly reproducible datasets.