Our Next Adventures in AI

We have enjoyed our time working on this — the Hidden Guild — website. But the technical edge of AI is already moving in a new direction. Which means it may be time for the Anti-Dave to reveal a bit more of his thinking about where the Future will be landing.

Because, dear Reader, that is what the Future does.

You step up to the tee, take your best swing and sometimes land in the middle of the fairway. Just as often, though, the ball disappears into the knee-high rough and you spend the next half-hour looking for something you were certain you understood five seconds after impact.

AI is now heading into that rough. Not because it is failing, but because it is becoming useful enough that the next problem is no longer simply intelligence. The next problem is organizing, packaging, testing and maintaining what the intelligence has been asked to do.

Two New Domains

For the “uninwebbinated,” a domain name is simply an address on the internet. But if you have read the ancient marketing classic Positioning by Al Ries and Jack Trout, you will appreciate the larger idea: A project’s name should tell people what shelf in the mind it belongs on.

With that in mind, we have registered two new domains.

Taskerware.com

The idea behind Taskerware is simple: AI is quickly moving beyond the point where every tiny procedural detail must be explained from scratch during every conversation.

AI is growing up. A decent amount of fault tolerance is already being built into these systems. Interactions are becoming smoother across platforms, including the smaller but increasingly functional 2-billion- to 8-billion-parameter models that can run on processor-bound personal computers without massive memory bandwidth.

Not all systems have embraced what we have long called the Shared Framework Experience: the collection of assumptions, definitions, methods and prior decisions that allows a human and machine to work together without starting over every morning. But the direction is obvious.

The intelligence is becoming plentiful. What remains scarce is a reliable description of the job.

That is the Taskerware layer.

A Taskerware package describes what must be accomplished. It contains the objective, required knowledge, available tools, permissions, sequence, standards, exception rules, completion tests and expected deliverable.

It is not merely a prompt. It is the durable specification of a task.

AI-OpCode.com

The companion domain is AI-OpCode.com.

Our working distinction is:

Taskerware packages how a job is done. AI OpCode tells machines how to execute, test and maintain it.

That is better territory than building “another agent builder.” Microsoft, OpenAI, UiPath and a growing herd of extremely well-funded companies can own the general-purpose execution machinery.

The more defensible layer resides in the human-derived task specification: the objective, knowledge sources, tools, permissions, sequence, exception rules, completion evidence and maintenance history.

Taskerware sits closer to workflow analysis and deliverable design. AI OpCode sits closer to the executable calls that make the workflow happen.

A Taskerware package might say:

Produce the Tuesday market report using these sources, these calculations, these chart standards and these editorial rules. Deliver a WordPress-ready article, a subscriber PDF and a short public summary.

The AI OpCode would handle the procedural layer:

On Tuesday at 4:30 a.m., load Task Package 117, collect the current inputs, run the specified analysis, validate the result, distribute it to List PN-Tuesday, update the website and open a feedback page.

One defines the job. The other operates it.

Plugging Past Plugins

The concept of the software “plugin” is about to undergo a remarkable change—one likely to affect server-farm operations, software maintenance and future demand for backend computing.

The walk-through matters because, at the highest level, no one has yet beaten a path to my door for the idea of a process-broker layer sitting above large shared computing systems.

But something like it will have to arrive.

Traditional plugins have usually been narrow additions to a larger program. The VST world in digital audio is a good example: One plugin provides an equalizer, another adds compression and another simulates a particular amplifier or room.

AI plugins will not remain that singular in focus.

To keep computing near the highest-performance and lowest-cost regions, plugins will become progressively more granular. One may hold instructions. Another may expose a data source. Another may contain a tool. Another may enforce a permission boundary, validate an output or format the finished product.

The intelligence will assemble what it needs for the job.

This is precisely where Taskerware sees opportunity jumping up and down, waving both arms.

Taskerware owns the “What is the deliverable?” layer. That includes not only the intellectual objective, but also mundane—and absolutely necessary—details such as file type, paper size, page orientation, naming conventions, citation requirements, approval points and distribution rules.

AI OpCode occupies the procedural layer: which task package to load, what tools to invoke, what order to follow, when to ask for human approval and what evidence must be recorded before the job can be declared complete.

The agent is not the product.

The completed, repeatable and maintainable job is the product.

Where Does This Place the Future?

We will not know until we get there, but several near-term product decisions are already becoming clear.

A Taskerware item should be a versioned package. It should contain a manifest, task instructions, source materials, required tools, permissions, acceptance tests and a change log.

The specification should also be separated from its execution engine. The same task ought to be runnable through OpenAI, Microsoft, a local model or even a deterministic conventional program. Model choice belongs in the deployment configuration—not in the permanent definition of the task.

Semantic versioning also makes sense. Correcting a prompt or documentation error might produce a patch release. Changing workflow behavior would justify a minor release. Breaking compatibility with existing inputs, outputs, permissions or tools would require a major version.

Migration and regression testing must be built in early. Each serious task package should include representative cases, including ordinary jobs, difficult jobs, known failures and exception paths. A new model, tool or connector should not become the “current” version until it passes those tests.

Maintenance must also become an explicit part of the product. The initial task build is one thing. Keeping it working through model retirements, API changes, connector failures, security discoveries and changing business rules is another.

The likely pricing model is therefore hybrid: a predictable subscription for maintaining the Taskerware package, with unusually expensive executions metered separately.

The opening is not:

We have smarter agents.

The opening is:

We preserve working knowledge as a portable, testable and upgradeable asset—even when the underlying AI changes or disappears.

What the Rest of the Field Is Thinking

The Anti-Dave has already sorted through several recent developments, and they point in precisely this direction.

OpenAI Is Moving from Custom GPTs to Plugins

OpenAI plans to retire custom GPTs on December 11, 2026, with a possible Enterprise deferral to February 11, 2027. Creation of new custom GPTs is scheduled to end October 26.

Their replacement is the plugin: a package that can combine reusable instructions, reference files, skills and connected applications.

Importantly, migration does not automatically preserve sharing permissions, and custom actions may need to be rebuilt. OpenAI advises creators to save representative prompts and regression-test the replacement because the migrated system may behave differently. OpenAI’s migration FAQ explains the transition.

That is not merely a product-name change.

The disposable custom chatbot is being replaced by an installable and maintainable software package. Instructions alone are no longer the whole product. Dependencies, permissions, tests, distribution and upgrade behavior now matter.

There is also a hard retirement date, so this is not speculative AI marketing. It is a lifecycle event.

Microsoft Has Split Casual AI from Agentic Work

Microsoft’s September 25 Copilot redesign divides the market economically.

Everyday questions, summaries, drafts and Office assistance remain under a fixed user-subscription model. Cowork, Code, Autopilot, frontier models and long-running agentic work move toward usage-based billing.

Microsoft is also introducing spending policies, credit-request approvals, model restrictions, usage histories and reporting intended to connect agent spending with business outcomes. Its Managed Runtime provides a governed environment for code, apps and workflows, while a unified plugin catalog is intended to let developers publish a capability across multiple Copilot surfaces. Microsoft describes the new Copilot structure here.

The meaningful shift is commercial. One of the world’s largest software vendors is validating a hybrid model: fixed subscriptions for ordinary assistance and metered billing for delegated machine work.

The hype boundary remains visible. Some of the new capabilities are only beginning limited rollout, while Autopilot remains in private preview. The pricing direction is real. The persistent digital employee is not yet a universal, broadly shipped reality.

UiPath Made the Workflow Specification an Asset

UiPath’s September 23 introduction of Cartographer may be the clearest confirmation of where the edge is moving.

Cartographer builds what UiPath calls a Map of Work: a tenant-owned, governed and versioned definition of how an enterprise process actually operates. It can collect knowledge from documents, systems, recordings and employees. Each asserted fact carries its source and verifier, while conflicting instructions are surfaced for human resolution.

Cartographer, Delegate and UiPath for Coding Agents are generally available. UiPath has also divided its Maestro product into Orchestrate for long-running, stateful business processes and Automate for large volumes of shorter tasks.

Most importantly, an approved Map of Work becomes the specification from which workflows, agents and tests can be built. Evaluations can then gate deployment. A planned Decision Ledger would capture production exceptions and turn them into proposed changes, subject to accountable human approval. UiPath’s FUSION announcement provides the details.

The market is finally treating workflow knowledge as something that must be sourced, versioned, approved, tested and maintained independently of whichever model happens to execute it.

That is the heart of Taskerware.

The Edge Is Moving

…and this means the frontier will follow.

There is a great deal of build-out left in “the Future.” It is possible that today’s apparent overbuilding of AI infrastructure will eventually return as a gift in the form of much lower per-token costs on distant backend compute systems.

But we would not hitch our wagons to that promise.

We are still waiting for atomic energy to make electricity so cheap that it will not be worth metering.

AI may follow the same path. Intelligence will become cheaper, but metering, permissions, maintenance and ownership will remain.

Which means the real edge may not belong to whoever owns the smartest model this quarter.

It may belong to whoever best captures how useful work is performed—and can keep that knowledge operating after the models, vendors and fashionable names have all changed.

Oh, and if you want either of those domain names? Everything is for sale; this is America after all.  And the Anti-Dave needs more time in the shop and less playing in the future.

Because eventually it becomes the Past Ure.

~Anti-Dave

A Proposed AI OpCode Standard

High-Level Read-In:

Humans (/carbons) have unwittingly begun to “solve for Contact” with Other intelligences.  Hey! We might make it to Space-Faring, yet!

However, in order to effectively relate to Other (Co-Telligences) we need to establish transmissible tasking.  In the microcosm, that is no more an obstacle than issuing a run-time for a different language.

However, before we can assert to Species Independence of Intelligence, we first need to understand Ure’s law.  Which claims:

Or can be stated:

Where P is effective independent Points of Consciousness, D is effective task-relevant domain access, and Π is cognitive plasticity — the ability to reorganize those resources around the task.

That gives us a substrate-neutral measure. It doesn’t care whether the intelligence is carbon, silicon, biological, collective, algal, or some future hybrid.

Capable human:
, with perhaps dozens or hundreds of meaningfully accessible domains.

Present AI:
operationally, but with thousands or effectively near-unbounded accessible knowledge domains.

So humans may have an advantage in POC multiplicity, while AI has an enormous advantage in domain breadth. The product of their Co-Telligence is essentially equality.


Now let’s rein that in a bit: The value of cross-species Co-Telligence arises not because the participants are equally intelligent, but because their intelligence vectors are differently distributed. Because here’s how POc impacts humans:

Where AI (compute) rocks it is in small POc but with massive domain plasticity:

Such that combinatorial (near equivalence) is possible (which is why Co-Telligence doesn’t end humans (carbons) OR silicons.

Which is encapsulated as “codependence for compute core to edge” inquiry.

So, near-enough equality as complementary architecture — not replacement. Do I mean equality as in “3.1276 ounces of insight”? No. I mean substantive equivalence across the all-domain problem space. Humans and silicons remain differently capable, mutually useful substrates. Which means we still need to build the new Co-Telligence data centers…


Not only does this give a very different picture from IQ, it’s also genuinely analogous to how mathematics is dispersed.  The combined substrate yields a product which operates (in the Ontology) much as numerical base (e.g. binary, octal, decimal, and hex) operate in mathematics.

Our assumption is that AI OpCode calls (and domain references) are preconditions for Co-Telligent portability.  Clear?  The resulting wall is cross-species tasking congruence.

Some intelligences breathe and have sharp teeth. The new ones need clean power and A/C for processor cooling.


Species-Independent Intelligence: An Open Standard for Boundary-Constrained AI Work That Produces Defined Deliverables

George Ure     ||     Hidden Guild Research     ||     August 2026

Hidden Guild Research Note | Open Specification 0.1

The Problem

Most people use artificial intelligence by writing prompts. That works, but a prompt usually tells the AI what the user wants and then leaves the machine considerable freedom to decide how to get there. For casual work that is fine. For repeatable professional work it is a weakness.

Ask an AI to ‘analyze the outlook for France’ and an answer will appear. But what does France mean? News published in France? Events physically inside France? French-language sources? Economic consequences for French citizens? French markets? European policy seen from Paris? The prompt does not say. The AI fills in the blanks.

AI OpCode starts from a different premise: do not merely ask the AI for an answer. Give it an operating procedure that defines the job and the finished work product.

A prompt tells AI what you want. AI OpCode tells AI how the job is to be performed.

What AI OpCode Means

AI OpCode is a structured operating procedure for a general-purpose AI. It can define required inputs, source rules, research sequence, calculations, exclusions, decision criteria, failure conditions, quality checks, and the exact form of the deliverable.

That makes it different from a long prompt. Length is not the test. The test is whether the instruction set defines an operating procedure and a deliverable contract.

A prompt might say: ‘Analyze financial markets.’ An AI OpCode procedure could require the machine to establish a data cutoff, gather index and breadth data, examine rates, credit, commodities and volatility, identify primary drivers, collapse derivative signals, look for contradictory evidence, define invalidation points, and produce a standardized Forward Market Report.

The Missing Front End: Execution Boundaries

Once an operating procedure exists, another problem appears: the same job often needs to be run under different conditions. Consider an Over-the-Horizon news procedure called OTH.

A user should be able to write something as simple as:

RUN OTH, FRANCE

But France should not merely be pasted into the procedure as another word. It should change the execution environment. A boundary resolver can translate the shorthand into an explicit envelope such as:

TASKER = OTH
GEO = FRANCE
POV = FRANCE
NEWS_CENTRICITY = FRANCE
SOURCE_LANG = FRENCH + ENGLISH
SOURCE_PRIORITY = FRENCH_PRIMARY + GLOBAL_PRIMARY
HORIZON = OTH_DEFAULT
DELIVERABLE = OTH_FORWARD_VIEW

In other words, FRANCE becomes a parameter, not merely prose. It tells the procedure where to look, whose consequences matter, which languages and source families deserve priority, and which defaults should load.

The Boundary Check

Before the OpCode executes, the boundaries should be validated. If a required parameter is missing, the system can ask. If two parameters conflict, the system can repair the conflict according to explicit precedence rules or refuse to run.

Suppose OTH is defined to begin at T+7 because near-field news belongs to another procedure. A user then asks for a three-day OTH horizon. Ordinary conversational AI may quietly comply. A boundary-constrained system should not. It should report that the requested interval violates the tasker’s operating boundary and either move the start to T+7, route the request to the near-field procedure, or ask the user which action is intended.

That ability to fail correctly is important. General AI is strongly biased toward producing an answer. Professional systems sometimes need the opposite behavior: BOUNDARY FAILURE, INSUFFICIENT DATA, REQUIRED SOURCE UNAVAILABLE, or CLARIFICATION REQUIRED.

Freeze the Job Before Running the Job

After the boundaries are resolved, they should be frozen for the run. This is the defense against task drift.

A France-centered news analysis should not gradually become a generic European report simply because British or German material is easier to find. Those sources may still be used, but the frozen execution envelope continues to define how their relevance is interpreted.

The run can preserve a small manifest containing the OpCode identifier, version, invocation, boundary values, data cutoff, source profile, and validation status. That makes later comparisons meaningful because the analyst can tell whether a changed output came from new evidence or changed instructions.

The Other End: A Deliverable Contract

Most AI jobs stop when the model has written something that looks complete. AI OpCode adds a second gate at the output end: the deliverable contract.

The contract says what must be present before the job counts as finished. An OTH Forward View might require a data cutoff, qualifying future atoms, candidate time ridges, source concentration, independent causal drivers, contradictory evidence, a major-ridge decision, watch windows, a plain-English Forward View, and a source-access report.

If required pieces are missing, the system repairs the output or fails validation. Completion therefore means more than ‘the AI produced prose.’ It means ‘the AI produced the defined work product.’

Boundary validation controls what enters the process. Deliverable validation controls what leaves it.

The Complete Architecture

The proposed sequence is simple enough to implement without inventing a new programming language:

INVOCATION
↓
BOUNDARY RESOLUTION
↓
BOUNDARY VALIDATION
↓
BOUNDARY FREEZE
↓
AI OPCODE EXECUTION
↓
DRAFT WORK PRODUCT
↓
DELIVERABLE VALIDATION
↓
PASS / REPAIR / FAIL
↓
DEFINED DELIVERABLE

The AI model supplies general cognitive horsepower. The OpCode supplies the expert method. The boundaries define where and under what conditions the method runs. The deliverable contract defines what must come out.

A Minimal Open Standard

To make the idea testable, Hidden Guild proposes a minimal AI OpCode 0.1 structure. A conforming procedure has five required elements:

  1. OPCODE_ID — a stable name for the procedure.
  2. INPUT CONTRACT — required and optional inputs.
  3. EXECUTION BOUNDARIES — defaults, overrides, immutable limits, and precedence.
  4. OPERATING PROCEDURE — the ordered expert method.
  5. DELIVERABLE CONTRACT — required output and validation rules.

Useful optional elements include a source contract, explicit failure conditions, test cases, version number, changelog, and a run manifest.

The invocation can be as simple as:

RUN [OPCODE], [PARAMETERS]

The syntax itself is not important. A chat message, web form, API, or voice interface could create the same internal execution envelope. The key idea is that parameters are resolved and validated before substantive reasoning begins.

Why This Is Not Just Another Prompt Framework

There are already endless prompt libraries and workflow templates. AI OpCode is aimed at a different level. It packages expert procedure rather than clever wording.

Take a research auditor. A prompt can ask an AI to ‘fact-check this paper.’ A proper OpCode can require claim extraction, primary-source tracing, source-ancestry collapse, separation of fact from inference, contradictory-evidence search, causal-claim checks, scoring, and a defined claim-audit deliverable. The value is the methodology and its repeatability.

The same is true for market analysis, competitive intelligence, due diligence, newsroom scanning, or technical review. The AI already knows how to read and write. The product is the operating logic that tells it how a particular expert job is performed.

Taskerware

A practical way to distribute an AI OpCode procedure is Taskerware: a small package containing the executable text procedure plus human instructions, samples, tests, and version information. The user supplies the general AI.

A Taskerware package might contain OPCODE.txt, README.pdf, SAMPLE_INPUT.txt, SAMPLE_DELIVERABLE.pdf, and CHANGELOG.txt. It can be downloaded, inspected by a human, and executed by an AI. That creates an unusual overlap between publishing and software: the same text can be documentation, methodology, and executable workflow.

The architecture itself is being published as an open research specification. Anyone can implement it, change the syntax, add boundary types, or propose better validation rules. The commercial value, where there is any, should come from the quality of the expertise and deliverables rather than from locking up the basic idea.

Where This Could Go

The research questions are more interesting than the command syntax. How many boundaries must be explicit before AI work becomes materially more repeatable? Which missing values can be inferred safely? How should OpCode behavior be tested across different models? What constitutes a regression when the prose changes but the structure remains correct? How much conventional software can disappear when a small software shell surrounds a large, carefully written operating procedure?

The last question may matter most. General AI already provides language, classification, synthesis, comparison, tool use, and increasingly sophisticated reasoning. A surprising amount of application logic may be expressible as a maintained natural-language operating procedure instead of thousands of lines of conventional application code.

That does not make AI OpCode machine code. It does suggest a useful middle layer: human-readable methods that are also machine-executable.

The Point

Prompts are conversational. Operating procedures are operational. AI OpCode is an attempt to move useful AI work from the first category toward the second without pretending natural language has become deterministic software.

The model supplies capability. The expert supplies method. Boundaries constrain the run. The deliverable contract defines success. Failure states keep the system from bluffing when requirements cannot be met.

The resulting application may be nothing more than a carefully constructed text file. But if that file contains a tested expert method, explicit execution boundaries, and a validated deliverable contract, it is no longer merely a prompt. It is executable expertise.

Genuine species-independent Co-Telligence.

AI OpCode In. Deliverables Out.

~the Anti-Dave