Adaptive Micro-Orchestration

What adaptive micro-orchestration means

A MicroSkill is intentionally narrow: it does one job through a stable contract. Real agent tasks are broader, though, so your agent often needs to choose a skill, combine it with another one, inspect the result, or repair an input before it can continue.

Adaptive micro-orchestration is the guidance layer around those local decisions. It brings together two parts of Squillify that your agent can use throughout a task:

• Contract guidance before and between calls. A MicroSkill can explain when to use it, when not to use it, which skills are related, and which skills it can be composed with.
• Runtime guidance after a failure. Guided Failure Recovery can return a typed reason plus ranked, accessible skills that may repair the input so your agent can retry the original MicroSkill.

We call it micro-orchestration because Squillify guides one bounded transition at a time, close to the MicroSkill that produced the signal. It’s adaptivebecause the next useful step can change with the agent’s intent, the contract it retrieves, the result it receives, and its current access and policy context.

Why ordinary tool calling isn’t enough

Giving a model a list of tool names and schemas tells it what it cancall. It doesn’t necessarily tell it which capability fits the current intent, what should come before or after it, or how to recover when a valid-looking plan meets a real input problem.

Without stronger guidance, your agent has to infer those transitions from names, prose, and trial and error. That creates room for the wrong skill, an incompatible chain, a pointless retry, or a recovery step that quietly changes the original goal.

Squillify keeps the reasoning surface smaller. Your agent can discover a focused capability, retrieve its contract, act on stable fields, and adapt from the result instead of rebuilding the surrounding logic from scratch every time.

How it’s implemented

There’s no hidden workflow engine behind the feature. Adaptive micro-orchestration comes from a few explicit layers that already sit in the normal Squillify discovery and execution path.

1. Intent-aware resolution

Your agent starts with a small foundation tool surface. When it needs a capability, it calls platform.skill_catalog_search. OSRE, Squillify’s skill resolution engine, searches and ranks the catalog inside the caller’s authorized scope.

This gives your agent a focused set of candidates without loading the full catalog into its context window.

2. Contract-native decision guidance

When your agent needs the full picture, it retrieves the selected MicroSkill through platform.skill_contract_get. Alongside the input and output schemas, the contract can carry guidance that helps the agent decide whether and how the skill belongs in the current task.

3. Contract-checked execution

Your agent calls platform.skill_execute with the chosen MicroSkill and its arguments. Squillify applies the normal validation, authorization, quota, policy, and execution checks before returning a structured result.

Those checks apply to every call in the path. A relationship in a contract is useful guidance, not permission to bypass the caller’s current access or the MicroSkill’s execution rules.

4. Runtime adaptation after failure

When a recovery-aware MicroSkill fails, Guided Failure Recovery can add a structured failure envelope and an advisory recovery block to the result. The failure tells your agent what happened using stable fields; the recovery block lists ranked skills that explicitly declare they can satisfy the repair intent and that the caller can access at response time.

Your agent chooses whether to call one of those skills. If it does, the follow-up call goes through the normal authorization, quota, and policy checks, and it is billed normally. Once the repair succeeds, the agent can retry the original MicroSkill without losing sight of the original goal.

The agent loop

Put together, the layers give your agent a compact decision loop it can follow one step at a time:

1. Your agent identifies the capability it needs.
2. It searches the authorized catalog and receives ranked MicroSkill candidates.
3. It retrieves the selected contract when it needs schemas, examples, boundaries, or composition guidance.
4. It executes the MicroSkill with contract-valid arguments.
5. On success, it uses the result and may continue with a declared related or composable MicroSkill when that serves the task.
6. On a recoverable failure, it can call a ranked recovery option, repair the input, and retry the original MicroSkill.
7. When no guided path is available, it falls back to its own handling or asks for help instead of inventing a Squillify capability.

Agent intent
  -> search the authorized catalog
  -> retrieve the selected MicroSkill contract
  -> execute
       |-- success -> use the result or continue with declared composition guidance
       |-- recoverable failure -> repair with a ranked accessible skill -> retry
       \-- no guided path -> use the agent's own fallback or escalate

Why it matters for AI agents

• Less guesswork. Your agent gets positive, negative, and relational guidance instead of relying on a tool name alone.
• Smaller context. It resolves the capabilities it needs on demand and retrieves detailed contracts only when they help.
• Safer composition. Declared relationships give the agent a better starting point than inventing a chain from semantic similarity.
• Useful failures. A recoverable error can become a typed branch toward inspection, repair, and retry instead of a dead end or a blind loop.
• Goal continuity.Recovery prepares the original MicroSkill for another attempt; it doesn’t quietly substitute a different goal.
• Governance at every step. Discovery and recovery guidance are scoped to the caller, while each actual execution still goes through the normal checks.
• Composable growth. New MicroSkills can publish their own selection and relationship guidance without requiring one central workflow definition to know every possible agent journey.

How it differs from a workflow engine

Both approaches are useful, but they solve different problems. A workflow engine is the better fit when you need a predefined sequence, durable state, centrally controlled branching, or a business process that must run the same way every time. Adaptive micro-orchestration is for agent-led work where the useful next step depends on what the agent discovers and what the last call returned.

What it does not do

Clear boundaries make the guidance easier to trust. Adaptive micro-orchestration does not:

• Execute a related, composable, or recovery skill automatically.
• Persist a workflow or keep durable process state for your agent.
• Map one MicroSkill’s output into another MicroSkill’s input automatically.
• Turn relatedSkills or composableWith into a guaranteed end-to-end pipeline.
• Bypass authorization, quota, billing, or runtime policy checks.
• Guarantee that a recovery option visible now will still be available when your agent calls it later.
• Invent a missing capability or silently change the agent’s goal.

When it’s a good fit

Adaptive micro-orchestration is especially useful when your agents work with a large catalog, receive inputs that vary in quality, or need to build a path dynamically from the result of each call. You get more guidance without handing control of the task to Squillify.

If your process has a mandatory sequence, long-running state, approvals, or compliance steps that must always happen in a fixed order, keep that process in your workflow system. Your workflow can still call Squillify MicroSkills inside individual steps — the two approaches work well together.