PATOIS

PATOIS Research Proposal v3

The originating brief, as authored by Bob McWhirter (2026-07-28), reproduced here as the repository’s statement of intent. It is the premise under test, not a set of findings. Where the experimental design departs from or sharpens this brief, DESIGN.md says so explicitly and gives the reason.

Abstract

PATOIS (Prompts As The Orchestration Intelligence Strategy) explores whether orchestration intelligence should live in MCP responses rather than exclusively in static prompts or application code. Inspired by HATEOAS, a response advertises not only data and affordances but also typed, scoped, authority-limited guidance that helps an agent decide what to do next.

The central premise is deliberately narrow: PATOIS is not primarily about improving the first tool call (0→1). It is about improving every tool call thereafter (1→n). Once an agent has successfully invoked a tool, the server has concrete application state and is uniquely positioned to publish local orchestration guidance. This work evaluates whether that guidance improves continuation of multi-step workflows while maintaining strong security boundaries against prompt injection.


Core Thesis

Current agent systems are reasonably good at deciding which tool to call first from a user request.

They are significantly less reliable at deciding what should happen next after receiving a tool result.

PATOIS proposes that orchestration should become response-driven rather than globally prompt-driven.

Primary Goal

Improve 1→n tool orchestration.

Not:

How does an agent discover the first tool?

Instead:

Once an agent has a successful tool response, can the response itself teach the agent how to continue?


Research Hypotheses


Mental Model

0 → 1

User intent → initial tool selection. (This is largely outside the scope of PATOIS.)

1 → n

Tool response (affordances + PATOIS guidance) → correct next tool → correct parameters → correct sequencing → successful completion.

PATOIS should make each successful tool response a new, locally self-describing orchestration surface.


Experimental Design

Compare:

The evaluation should emphasize continuation quality after the first successful tool invocation.


Primary Metrics

Measure continuation performance:

Bootstrap (0→1) metrics should still be collected but treated separately.


Security Model

PATOIS guidance is:

Invariant:

PATOIS may influence how an authorized capability is used. It may not create authority, expand scope, or replace the user’s goal.


Trace Collection

Capture every run:

Unexpected behavior should be preserved rather than filtered.


Research Diary

For every surprising outcome record:


Immediate Next Steps

  1. Build deterministic mock MCP server.
  2. Implement Conditions A–D.
  3. Focus the first experiments on 1→n continuation rather than initial discovery.
  4. Introduce adversarial guidance after establishing a baseline.
  5. Iterate PATOIS only in response to evidence.