AI Agent Capability Routing on Android: AutoAttach, Suggest, Fallback, and FoneClaw

Turn One Android Request Into Ranked Candidates

AI agent capability routing is the step that turns a user request into a short, ranked set of possible capabilities before anything runs. Imagine the user says, “Read this screen, save the important follow-up, and remind me tomorrow.” A phone agent should not load every tool, Skill, Workflow, and Plugin into the active context. It should narrow the field: current-screen reading, note extraction, memo creation, reminder or calendar action, and a confirmation path if the result changes the phone.

The ranking starts with the request, but it should not stop at keyword matching. The agent needs context metadata: current app, visible screen type, user intent, recent task state, installed capability state, permission availability, and whether the action is read-only or consequential. A memo tool may rank highly when the user asks to save a note. A calendar tool may rank higher when the wording includes a date and time. A workflow may rank higher when the user repeats a known multi-step pattern.

Semantic matching is only a candidate signal. It does not authorize execution, install a Plugin, grant a permission, or approve a sensitive action. That distinction is where many agent designs fail. The router’s first job is to produce a useful candidate set with a confidence score and reason. The next states decide whether context is attached, the user sees a suggestion, a fallback is needed, a capability is activated, an approval is required, and the Android action can be executed and verified.

For the general vocabulary of Tools, Plugins, Skills, Workflows, and Shortcuts, FoneClaw Tools, Plugins, Skills, Workflows, and Shortcuts Explained keeps the capability-layer glossary in one place. This guide focuses on the routing mechanics after a real Android request arrives.

Choose AutoAttach, Suggest, or Fallback

Once candidates exist, the router needs a behavior mode. In FoneClaw terms, the useful split is AutoAttach, Suggest, and Fallback. These terms sound close, but they represent different levels of confidence and user involvement. Treating them as one feature would make routing too aggressive. Treating them as separate modes lets the agent help quickly while preserving control when the route is uncertain.

AutoAttach is for high-confidence, low-risk context attachment. If the user asks about the current screen and FoneClaw can attach the screen state the user explicitly surfaced, AutoAttach can add that local context or capability metadata to help the model reason. AutoAttach does not run the tool, send a message, change a setting, or install anything. It makes the next reasoning step better.

Suggest is for a visible choice. If the router sees two good paths, such as saving a memo or creating a calendar item, Suggest should show the user the best options instead of guessing. Suggest is also right when a Plugin, Skill, or Workflow may help but the user should decide whether to use it. The user sees the proposed route before activation or action.

Fallback is the safe continuation path when the router cannot match confidently, when a dependency is missing, when a permission is denied, or when the exact target is ambiguous. Fallback does not bypass policy. It turns uncertainty into a clear next step: ask a clarifying question, use a simpler built-in tool, open a settings recovery path, save a draft, or stop with a visible reason.

In the earlier reminder example, AutoAttach can add the current screen if the user asked from the floating assistant. Suggest can ask whether “important follow-up” should become a memo or a calendar reminder. Fallback can ask for the missing date if “tomorrow” cannot be resolved from device time or if calendar permission is unavailable.

Discovery, Attachment, Activation, Approval, and Execution

Capability routing needs a state machine because the same word “available” can mean several different things. A capability can be discovered, attached as context, installed, activated, approved for a task, executed, and verified. Those states should not collapse into one flag.

Discovery means the agent can find a relevant capability candidate. In the broader ecosystem, Google describes Agent Plugins as an open, vendor-neutral packaging approach for Agent Skills, MCP servers, and shared metadata. GitHub’s Agent finder shows the same pattern from another angle: relevant resources can be ranked on demand while respecting configured registries and settings. Discovery gives the router options; it does not install or execute them.

Attachment means relevant local context or metadata is brought into the reasoning step. It can help the model decide whether a built-in tool, Skill, Workflow, or Plugin path makes sense. Attachment should be bounded to the task and user-visible context. It should not become a quiet way to over-share unrelated phone state.

Activation means a capability is enabled for use under the product’s lifecycle rules. A discovered Plugin may need review. A Skill may need preview and confirmation before it becomes an available draft. Dependencies may need to be present before activation can succeed. Activation prepares a capability for possible use, but the next Android action may still require approval.

Approval is the user-facing decision point for consequential work. Sending, sharing, calling, deleting, posting, purchasing, changing settings, using private data, or granting permissions deserves a clear final checkpoint. Execution and verification happen after the approved tool path runs and the agent checks the visible result. For deeper registry and trust mechanics, Agentic Resource Discovery: ai-catalog.json, Tool Trust, and Phone Agent Authorization covers the discovery layer this page intentionally leaves separate.

Use Manifests, Dependencies, Metadata, and Confidence

A good router needs structured inputs. The first input is identity: what capability is being considered, what it claims to do, and which lifecycle state it is in. Plugin and Skill metadata helps describe the capability, but metadata alone is not trust. It is a routing input that still needs review, dependency checks, activation state, and action approval.

Dependencies come next. A Plugin may rely on a service, permission, account, local app, or supporting capability. A Skill may require a particular built-in tool. A Workflow may need several steps to remain available. The router should resolve dependencies before presenting a route as ready. If a dependency is missing, the system should show a recovery step rather than sending the model into a loop that keeps trying a path that cannot run.

Context metadata makes ranking more accurate. Current app, visible screen, selected text, recent user intent, device state, permission status, language, and task history can all change the best route. The same sentence can mean different things in Gmail, Maps, Calendar, a browser, or a messaging app. Context-aware capability matching should use only the context needed for the task and should keep sensitive details behind visible user control.

Confidence is the final routing input, and it should be handled conservatively. High confidence can justify AutoAttach for bounded context. Medium confidence often belongs in Suggest. Low confidence belongs in Fallback. A false positive can be more costly than a no-match: choosing the wrong contact, wrong app, or wrong setting creates user risk. Atomic capability snapshots help avoid partial active states when refresh or dependency resolution fails, so the agent can continue from the last accepted capability set instead of mixing old and new assumptions.

Skill security deserves its own depth because a useful Skill can still touch sensitive phone areas. AI Agent Skill Security Needs Phone Permission Checks explains why permission review remains part of the route even when the capability match looks strong.

Recover From Missing, Stale, Denied, or Ambiguous Routes

Capability routing should be judged by how it handles failure, not only by how it behaves when everything matches. Missing capability is the simplest case. If no built-in tool, Skill, Workflow, or reviewed Plugin can perform the request, the agent should say what is available, offer a safer adjacent route, or ask whether the user wants to create or review a capability. It should not invent hidden control over the phone.

Stale capability is different. A Plugin may have changed, a dependency may be unavailable, a local app may be removed, or a cached snapshot may no longer match the current environment. The router should detect the stale state and return to activation review, dependency repair, or the last accepted capability snapshot. A model retry cannot fix a capability that is not actually available.

Denied permission is another separate recovery path. If the user asks for a calendar action and calendar permission is missing, Fallback should open a permission explanation or settings path when appropriate. Task continuity matters here: the agent should preserve the user’s goal while the permission is repaired, then resume from a known state. Permission recovery is not the same as trying a different prompt.

Ambiguity needs visible clarification. If there are two contacts named Alex, two calendar apps, or two possible destinations, the router should ask the user to choose. When confidence is low, Fallback is more useful than pretending certainty. For approval design after a route is selected, AI Agent Approval UX on Phones: Confidence, Rationale, and Recovery shows how confidence and visible confirmation fit together.

Governed Capability Routing in FoneClaw

In FoneClaw, we built capability routing around a practical Android truth: matching a capability is only the start. The user’s phone still has permissions, app state, visible screens, sensitive actions, and recovery needs. FoneClaw routes among 100+ built-in tools, Skills, Workflows, and reviewed Plugins, then keeps activation, approval, execution, and result checking as separate stages.

Here is how the same reminder request moves through FoneClaw. The user opens the floating assistant over a screen and asks, “Save the important follow-up and remind me tomorrow.” The current-screen context can be attached when the user triggers that path. Local matching ranks candidates such as screen reading, summary extraction, memo creation, calendar or reminder creation, and a possible Workflow if the user has a saved pattern. The router scores the candidates using task wording, visible context, available tools, permission state, and previous task state.

AutoAttach is useful when the current screen is clearly relevant and bounded to the request. Suggest appears when the agent has a choice to present, such as saving a memo versus creating a calendar reminder. Fallback handles the gaps: unclear date, missing permission, no matching Workflow, unsupported target app, or ambiguous extracted text. These routes help the user continue without turning routing into automatic execution.

FoneClaw’s governed extension lifecycle reinforces that boundary. Plugin activation is reviewed before a Plugin becomes usable. Skill learning uses preview and confirmation before saving a disabled draft, so a learned capability starts in a controlled state. Atomic capability snapshots keep the active set stable when refresh fails. These product choices let the agent reason over capabilities without quietly changing the user’s phone authority.

Execution remains approval-aware. If the final route creates a reminder, sends a message, dials a number, changes a setting, or touches private data, FoneClaw shows the result and keeps the user in control at the consequential step. If the action cannot continue, FoneClaw gives a recovery path: grant a permission, resolve ambiguity, choose another route, save a draft, or stop. Current user-facing capabilities are summarized on FoneClaw Features.

Seven Checks for a Capability Router

Use these seven checks when designing or evaluating AI agent capability routing on Android.

1. Candidate quality. Does the router produce a small ranked set instead of dumping every tool into context?
2. False-positive control. Does the router avoid attaching, suggesting, or activating the wrong capability when names or intents are similar?
3. No-match behavior. Does the agent offer a clear Fallback when no supported route exists?
4. Dependency state. Are app, permission, account, Plugin, Skill, and Workflow dependencies checked before activation or execution?
5. Lifecycle separation. Are discovery, attachment, activation, approval, execution, result, and recovery separate states?
6. Approval boundary. Does consequential work remain visible and confirmable after the route is selected?
7. Recovery evidence. Does the system preserve task continuity when permission, app state, ambiguity, or capability refresh interrupts the flow?

Test both a clear match and a no-match case. For a clear match, use a reversible task such as extracting a note from the current screen and preparing a reminder. For a no-match case, ask for a specialized action that is not installed or activated. A capable router should help in both cases: fast attachment when confidence is high, visible suggestion when the user should choose, and Fallback when the safest next step is recovery or clarification.