FreeForm Harness: A Mobile-Native Agent Harness for Open and Composable Extensions

arXiv:2611.04579v1 [cs.SE] 3 Nov 2026

FreeForm Harness: A Mobile-Native Agent Harness for Open and Composable Extensions Bo Zhang∗

Pengbo Zhang

Amap, Alibaba Group Beijing, China cleroman@163.com

Amap, Alibaba Group Beijing, China

Jiaxin Jiao

Yue Liu

Amap, Alibaba Group Beijing, China

Amap, Alibaba Group Beijing, China

Abstract

1

Mobile phones already contain the capabilities required by many everyday agent tasks, but current mobile agents expose them only through monolithic pipelines with no open recombination point. Users and third parties therefore cannot publish, install, and compose new behaviors, and the personalized long tail of daily-life requests remains largely unserved. We argue that the missing piece is not capability but substrate. This is a Web infrastructure problem: the phone is now the Web’s dominant access point, yet the Web’s defining property, open publication and composition under decentralized authorship, stops at the agent harness. We present FreeForm Harness (FFH), a mobile-native agent harness for open and composable extensions. FFH separates what must always be present from what should remain freely replaceable: a frozen base and a permanence-aware required layer absorb mobilenative constraints such as location, proactive triggering, and scarce channels, while a uniform plugin contract keeps independently authored extensions composable, checkable, and replaceable over a frozen socket set. FFH also extends openness from third-party publication to end-user authorship through a tiered commissionedauthoring path: when no existing extension matches a user’s intent, a Web coding agent produces a candidate artifact that is still validated and admitted on device under the same contract discipline as any other extension. An Android prototype realizes FFH across device, market, and cloud. Evaluation establishes three results: the claimed architectural boundaries are enforced in the running system; realistic daily-life requests fit the declared composition space without requiring it to widen; and the full path from user intent to on-device execution closes through retrieval or commissioned authoring while final trust decisions remain device-local. FFH thus advances the agentic Web from “everything is a plugin” toward “everyone is a developer” on mobile.

Keywords

“Remind me to pick up my package when I’m almost home.” A phone already has the needed pieces. It can track location, receive delivery notifications, keep state for hours or days, and show a reminder through a banner, widget, or badge without interrupting the foreground app. What is missing is not capability but an open recombination point. Today’s mobile agents expose these capabilities only through fused pipelines. Users cannot install a new behavior that combines them differently, and third parties cannot publish an extension that others can install. This gap reflects a broader long tail of everyday requests: remind me to buy milk when I pass a supermarket; if rain is forecast and I am still outside, tell me to head home; fill my walk to work with financial news interleaved with navigation prompts. These requests reuse many of the same building blocks, but combine them differently for different users. No vendor can pre-build this long tail, because it is precisely the space of user-specific combinations. The problem is therefore architectural. More and more value now reaches the user through Web services, but it is finally combined and acted on at the device edge. The phone is the Web’s dominant access point, yet the Web’s defining property, open publication and composition under decentralized authorship, stops at the agent harness. Current mobile agent systems provide no open point at which a third party can publish an extension, have it discovered, verified, admitted, and executed on another user’s device without vendor permission. The missing piece is not simply a better mobile assistant. It is a mobile harness that carries Web openness all the way to on-device agent execution. Two requirements follow. First, the extension surface must be open: parties other than the vendor, in principle including the user, must be able to author new behaviors. Second, composition must remain general: because the long tail comes from recombining shared capability pieces in user-specific ways, the architecture cannot hardwire only a small set of favored combinations. Mobile agents therefore need open and composable extensions. Current systems still fall short of both. End-to-end mobile GUI agents such as AppAgent [22], Mobile-Agent-v3.5 [18], and MobiAgent [20] package capability inside fused pipelines. Some are modular internally, but their parts are not externally installable or replaceable at runtime. Siri and Google Assistant do expose selected mobile behaviors, including location-based reminders, but only as

Introduction

agentic Web, mobile agent harness, software architecture, composable extensions, uniform plugin contract, end-user authoring

∗ Corresponding author.

Bo Zhang, Pengbo Zhang, Jiaxin Jiao, and Yue Liu

(a) Today: capabilities exist, but are fused “Remind me to pick up my package when I’m almost home.”

(b) The long tail is personal Milk when I pass a market

user intent

remind

location

event

state

remind

plugin

new extension

Web coding agent (external)

L2 — open, composable surface Rain + still out → head home

Location

location

(c) FFH: absorb constraints, open the surface

plugin

plugin

plugin

Delivery event

any party may publish / install

⋯

new

uniform plugin contract

Durable state

Reminder surface

Monolithic pipeline

Walk-to-work briefing

location

news

nav

… user-specific combinations

fused · closed to extension

× No installable path × No recombination point

L1 — required infrastructure (i) location

(ii) triggers

(iii) channels / resources

one shared source

survives kill

one holder

Same pieces, different combinations

L0 — kernel + assembly

No vendor can pre-build all

Open + composable → everyone is a developer

Figure 1: Conceptual overview. (a) The pieces needed for the motivating request already coexist on the phone, but current agents fuse them into a monolithic pipeline with no installable path or recombination point for users or third parties. (b) The personalized long tail recombines the same pieces in user-specific ways, so no vendor can pre-build it. (c) FFH absorbs location, proactive triggering, and scarce channels or resources into required infrastructure 𝐿1 , leaving an open, contract-governed 𝐿2 where any party may publish or install extensions, including user-commissioned ones via a Web coding agent. built-in features. More registry-oriented systems move closer to modularity, but authorship remains developer-centered and admission remains tied to a managed registry rather than an open extension surface. On the desktop, DeepSeek Harness and Cordis [11] show an important alternative: an agent can be organized as a plugin substrate rather than as a monolithic assistant. But the mobile case is harder. The long tail here is personal, context-sensitive, and shaped by user-specific choices of trigger, data source, output modality, and threshold. On mobile, the plugin-substrate line should extend from everything is a plugin toward everyone is a developer: users should be able to state intent, have the system commission the missing extension on their behalf, and still admit the result under the same on-device contract discipline as any other plugin. The difficulty is that mobile openness cannot come from making everything optional. Three constraints become central once the authoring surface opens: location and mobility, proactive triggering, and scarce channels and exclusive resources. Location is a changing execution context; trigger commitments must survive process death; and independently authored extensions may compete for the same presentation slot or platform-level exclusive resource. If each extension handles these constraints itself, the result is duplication, interference, and lost continuity. Mobile openness therefore requires always-present infrastructure that absorbs these constraints once so that behaviors above it can remain open. We present FreeForm Harness (FFH), a mobile-native agent harness for open and composable extensions. FFH separates what must always be present from what should remain freely replaceable through three layers: a frozen base 𝐿0 , a replaceable-butpermanent required layer 𝐿1 , and an open extension layer 𝐿2 for independently authored plugins. A uniform plugin contract spans 𝐿1 and 𝐿2 , keeping extensions composable, checkable, and replaceable, while 𝐿1 absorbs location, proactive triggering, and scarce-resource contention through always-present authorities. FFH also extends openness from third-party publication to end-user commissioning. Users can install, compose, and replace extensions directly. When no existing extension matches a user’s intent, the user can state that intent in natural language, a Web coding agent can generate a candidate artifact, and FFH validates and admits that artifact on device under the same contract discipline as any other extension.

Commissioned authoring is not a privileged bypass, but another path into the same extension surface. Figure 1 gives the overview, and Figure 2 previews the architecture. Our contributions are: (1) A permanence-aware architecture for open mobile agents. We identify the missing architectural boundary for mobile openness and introduce a three-layer harness that separates a frozen base, a replaceable but permanent required layer, and an open extension layer. (2) Constraint absorption as the condition for mobile openness. We show that location, proactive triggering, and scarceresource contention must be absorbed into always-present authorities, allowing open extensions to remain composable above them under a uniform contract. (3) A unified extension lifecycle from publication to enduser commissioning. We present a retrieval-first, tiered authoring model that subjects published and AI-generated extensions to the same on-device validation and admission process. (4) An end-to-end Android realization and evaluation. We implement FFH across device, market, and cloud, and show that its architectural boundaries are enforced in the running system, its declared composition space covers realistic daily-life requests without widening, and its extension pipeline closes from user intent to admitted on-device execution while final trust decisions remain device-local.

2 The FreeForm Harness Architecture 2.1 Three-Layer Structure An open mobile harness must satisfy two requirements from Section 1: the extension surface must be open, and composition must remain general. On a phone, however, some guarantees cannot be left to optional extensions: location is a changing execution context, trigger commitments must survive process death, and independently authored extensions may compete for scarce channels or exclusive resources. The architectural question is therefore not whether these constraints exist, but where they belong. Two simple designs fail. A monolithic agent keeps all critical machinery present, but gives up openness. A fully dynamic plugin system keeps everything replaceable, but cannot guarantee that

FreeForm Harness

uniform plugin contract (Def. 1)

User intent

Retrieve first Marketplace

hit miss

retrieval · publication substrate

Tiered validation

Device-local admission

Commission · Web coding agent

L2 · open extensions — replaceable · non-permanent · composition dimensions (Defs. 2–3) Trigger

Data

Action

Slot

Asset

L1 · required layer — replaceable · permanent · absorbs mobile constraints once Location Source · single producer

Intake + Wakeup · durable triggering

Resource Arbiters · single-holder leases

L0 · frozen base — kernel + assembly · non-replaceable · permanent · bootstrapping · semantic uniqueness

Figure 2: Architecture overview. FFH comprises a frozen base 𝐿0 , a replaceable-but-permanent required layer 𝐿1 , and an open extension layer 𝐿2 . The uniform plugin contract (Definition 1) spans 𝐿1 and 𝐿2 , fixing the plugin-facing boundary with implementations replaceable. 𝐿1 absorbs location, proactive triggering, and scarce-resource contention via always-present authorities; 𝐿2 supports composition over trigger, data, action, slot, and asset dimensions (Definitions 2–3). Top: the retrieval-first authoring path—retrieve on hit, commission on miss, then tiered validation and device-local admission under one discipline. the components needed for location, triggering, or resource control will still be present in every execution. The difficulty is not a fundamental trade-off between openness and control; it comes from conflating two different properties. A component is replaceable if it conforms to a declared interface, states its dependencies explicitly, and can be swapped without changing its neighbors. A component is permanent if the architecture guarantees that some implementation of it is present in every execution after bootstrap. Replaceability concerns whether an implementation may change; permanence concerns whether the role may disappear. This distinction yields FFH’s three-layer structure. FFH separates the harness into non-plugin machinery K and plugins P. The frozen base is 𝐿0 = K, which is non-replaceable and permanent. It bootstraps the plugin system and fixes semantics that cannot vary at runtime. Among plugins, the replaceable-yetpermanent subset is 𝐿1 ⊆ P, the required layer. Its members may be replaced by other conforming implementations, but some implementation of each required role must always be present. The remaining plugins form 𝐿2 = P \𝐿1 , the open extension layer. These plugins are replaceable and non-permanent: they may be installed, removed, and recombined freely. Table 1 operationalizes this partition by distinguishing bootstrapping and semantically unique elements (𝐿0 ), permanent-butreplaceable roles (𝐿1 ), and the removable remainder (𝐿2 ). The key architectural move is 𝐿1 . Because no plugin on the open surface can be assumed present, FFH assigns permanence only to infrastructure whose absence breaks at least one always-required wing—safety, authoring, or continuity—as defined in Table 1. The partition is complete by construction: K and P are disjoint and exhaustive; 𝐿0 contains the bootstrapping and semantically unique elements; every plugin then lands in exactly one of 𝐿1 or 𝐿2 under Table 1. Where several implementations realize the same required role, permanence attaches to the role rather than to any one implementation. Appendix A records the complete membership witness. This partition lets FFH remain open without giving up mobile guarantees: 𝐿0 and 𝐿1 carry what must persist, while 𝐿2 remains freely installable, removable, and replaceable above them. Section 2.2 defines the uniform contract that governs all plugins, and Section 2.3 shows how the required layer absorbs the mobile constraints that openness cannot safely leave to chance.

2.2

Uniform Plugin Contract

The three-layer split answers what must remain present. The next question is how components across those layers interoperate without knowing each other’s implementations. FFH therefore uses one uniform declaration surface for all plugins. It inherits the plugin model of Cordis [11], where compatibility is checked over declarations rather than discovered through runtime calls. FFH extends that model for mobile by lifting into the declaration surface facts that would otherwise remain implicit until runtime, including hook ownership and interception, event emission authority, configuration type, and activation policy. The purpose of Definition 1 is not to formalize every runtime detail, but to make interaction-relevant facts explicit enough for pre-execution compatibility checks and coherent replacement. Definition 1 (Plugin Descriptor). A plugin descriptor is the plugin’s complete declaration surface. Formally, a descriptor is a 9-tuple 𝑑 = ⟨𝑅, 𝑂, 𝑃, 𝐻𝑜 , 𝐻𝑏 , 𝐻 𝑤 , 𝐸, 𝐶, 𝛼⟩ where: • 𝑅 ⊆ ServiceKey is the set of required services. • 𝑂 ⊆ ServiceKey is the set of optional services. • 𝑃 ⊆ ServiceKey is the set of provided services. • 𝐻𝑜 ⊆ HookPoint is the set of owned hook points. • 𝐻𝑏 ⊆ HookPoint is the set of observed hook points. • 𝐻 𝑤 ⊆ HookPoint is the set of wrapped hook points. • 𝐸 ⊆ EventPrefix is the set of event prefixes the plugin may emit. • 𝐶 is the type of runtime configuration accepted by the plugin. • 𝛼 ∈ {eager, lazy} ∪ ({event} ×2EventPrefix ) is the activation policy. Well-formedness requires 𝑅 ∩ 𝑂 = ∅. Each optional dependency in 𝑂 must have a declared default behavior. An instance may omit a key from the class’s 𝑅 only when its configuration selects execution paths that never invoke it; the sandboxed trial enforces this premise. Because interaction-relevant facts are declared in bounded form, three guarantees follow. Static checkability: assembly compatibility can be checked before code executes. No hook point may be owned by more than one plugin; no hook point may be observed or wrapped without an owner; wraps may short-circuit whereas observes may not; and every event-triggered activation must name

Bo Zhang, Pengbo Zhang, Jiaxin Jiao, and Yue Liu

Table 1: Layer partition criteria. Layer

Replaceability

Permanence

Membership criterion

𝐿0 (kernel)

Non-replaceable

Permanent: absence either halts the plugin system or violates a harness invariant

At least one of: (1) Bootstrapping: without 𝑐 , the plugin system cannot operate or plugins cannot interpret each other’s declarations. (2) Semantic uniqueness: the harness admits only one legal semantics for 𝑐 . For normative assets like rules, what is fixed is the rule text or declared meaning, not whichever executor applies it. Allowing several runtime-selectable semantics here would turn a harness invariant into a mere default.

𝐿1 (required)

Replaceable

Permanent: absence breaks at least one always-required wing

Both of: (1) Three-wing absence test: without 𝑐 , at least one of safety (a path exists on which the user may be harmed without awareness, including privacy loss, financial cost, or data loss), authoring (the intent–generate–validate–apply loop cannot proceed), or continuity (the agent ceases to be continuously present: state is not durable, process revival is impossible, or no unique source of external-world facts remains) is violated. (2) Non-bootstrapping: the plugin system itself remains operable without 𝑐 .

𝐿2 (open)

Replaceable

Non-permanent: freely

Conforms to the plugin contract, and its absence violates none of the three wings of the 𝐿1 criterion.

only prefixes that some plugin may emit. Provider uniqueness: each service key admits at most one provider across all instances, eliminating contract-surface ambiguity. Capability narrowing: for declarative and scripted payloads, the runtime mediates interaction through the descriptor; native Tier-3 payloads are bounded by provenance, admission, test-base evidence, and crash containment. Some facilities (e.g., clock, dispatchers, configuration, packagelocal assets, and private storage) are ambient runtime provisions rather than per-plugin grants. Uniform provisioning means a common interface, not shared access: namespaces remain isolated and event emission remains bounded by declared prefixes. At the instance level, FFH allows only narrowing relative to the plugin class. Let 𝑑𝑐 be a class descriptor and 𝑑𝑖 an instance descriptor. Then 𝑑𝑖 ⪯ 𝑑𝑐 ⇐⇒ 𝑅(𝑑𝑖 ) ⊆ 𝑅(𝑑𝑐 ) ∧ 𝑂 (𝑑𝑖 ) ⊆ 𝑂 (𝑑𝑐 ) ∧ 𝛼 (𝑑𝑖 ) ⪰ 𝛼 (𝑑𝑐 ). Here ⪰ is the admission ordering over trigger generality, with eager ≺ lazy ≺ event. When both class and instance are eventtriggered, the instance’s prefix set must be contained in the class’s declared prefix set. When the class is eager or lazy, any eventtriggered instance must draw its prefixes from 𝐸 (𝑑𝑐 ). Two runtime commitments keep a changing system coherent. Spatial coherence: dependencies in 𝑅 and 𝑂 are resolved against the live registry, and an absent required service suspends the dependent rather than failing it. Temporal coherence: every contribution registers as a reversible effect, so unloading a plugin leaves no residue in registries, event buses, or schedulers.

2.3

Constraint Absorption

The contract makes plugin structure explicit, but it does not govern shared mobile resources. If no always-present authority controls such a resource, each plugin manages it locally and none can predict or reconcile the rest. On a phone, this problem appears most sharply in location, proactive triggering, and scarce channels or exclusive resources. FFH addresses these by placing each contested resource under an always-present authority in 𝐿1 . Plugins declare only local needs and effects, but the global guarantees those declarations rely on are enforced once in required infrastructure. These authorities are plugins rather than hardwired kernel code: their roles are permanent, though their implementations remain replaceable. Location → Location Source. If location is left to open extensions, each may start its own producer with its own sampling policy, wakelocks, and accuracy requests. Battery cost then scales

with the number of consumers, and spatial semantics fragment across policies. FFH instead enforces a single-producer invariant: one 𝐿1 plugin is the sole producer of location facts for the harness. It governs sampling and accuracy, tags facts with their coordinate reference system, and normalizes them before exposure to consumers. Proactive triggering → Intake Dispatcher + Background Wakeup. Trigger commitments must survive process death, so they cannot live only inside transient plugin state. Left to open extensions, triggering loses both durability and integrity: no common baseline records what commitments should exist after revival, and orphaned registrations or duplicate wake paths have no single authority to reconcile them. FFH absorbs this constraint with two 𝐿1 authorities. The intake dispatcher governs arrivals while the process is alive: it normalizes external arrivals into log facts, applies queue-or-preempt policy, and wakes the agent loop. The background wakeup authority governs persistence across process death: it owns the durable registration ledger for declared conditions and reconciles it against the event log on revival, while the host exposes platform scheduling handles through a reserved seam. The key invariant is write-ahead registration: every registration or cancellation of a scheduling handle must first be recorded in the log. The log is authoritative at revival. Reconciliation is idempotent: handles without log backing are discarded, logged registrations missing a live handle are re-established, and logged cancellations backed by a live handle are revoked. FFH does not override platform power policy; its claim is narrower: trigger commitments remain durably represented and mechanically recoverable across process death, subject to the wake paths the platform permits. Scarce channels and exclusive resources → Exclusive-Resource Arbiter. Some resources must be held rather than merely read, including platform-arbitrated resources such as audio focus and camera, and FFH single-writer leases over logical resources such as a presentation slot or a location subscription. Left to open extensions, such resources produce interference that no plugin can resolve alone. FFH absorbs this constraint through an 𝐿1 exclusiveresource arbiter. Each governed resource is represented as a named lease with at most one holder. Plugins claim resources through the contract surface and declare how they should be treated when the resource is busy. The arbiter resolves contention with priority, epoch-based invalidation of stale holders, and a three-state disposition of interrupt, defer, or discard. Requests that need several

FreeForm Harness

leases acquire them through one arbiter-coordinated transaction, so either all required leases become valid together or none do. Taken together, these authorities are the operational content of 𝐿1 : open plugins declare local needs and effects, while the mobile guarantees are enforced once in always-present infrastructure.

2.4

Composition Model

With mobile constraints absorbed into 𝐿1 , FFH composes 𝐿2 behaviors by configuration, following Cordis and DeepSeek Harness [11]: an interpreter class fixes the execution envelope, and a typed runtime specification fixes behavior within it. For the reactive mobile behaviors studied here, a specification must capture five choices: when it fires, what information it draws on, what effect it produces, where that effect appears, and what static content it carries. FFH therefore projects each specification into five dimensions: trigger, data, action, presentation slot, and asset. Architecturally, these five dimensions are the declarative envelope for the reactive-mobile class studied here; §4.2 confirms that every benchmark case projects into this envelope without widening it. Definition 2 (Composition Space). A plugin specification 𝑠 is projected into a five-dimensional composition space 𝜋 (𝑠) ∈ B = T × D × A × S × A∫, whose dimensions correspond to trigger, data, action, presentation slot, and asset. The point of this projection is architectural: many new behaviors differ only in how these five choices are combined, not in requiring a new pipeline or interpreter. Definition 3 (Dimension Orthogonality). Fix a declarative crossconstraint set Ξ over dimension values, represented as a finite set of predicates stored in the contract’s rule assets. For a fixed interpreter class, two dimensions 𝑋𝑖 and 𝑋 𝑗 of B are orthogonal relative to Ξ if changing an admissible value in one dimension, while holding the others fixed, yields another admissible specification whenever the resulting tuple does not violate Ξ, and if adding a new value to either dimension requires no change to the interpreter class or to existing specifications. In plain terms, one dimension can vary without rewriting interpreters or existing specifications unless a declared cross-constraint forbids the combination. This separates the candidate space of combinations from the admissible subset selected by the interpreter envelope and Ξ. For a finite snapshot, adding one new value to dimension 𝑋𝑖 expands the candidate space by Ö |B ′ | − |B| = |𝑋 𝑗 |. 𝑗≠𝑖

Architecturally, widening one dimension multiplies combinations through the others without requiring new pipeline code. The five dimensions do not exhaust 𝐿2 : native algorithms remain code-based plugins, and new engines remain outside the declarative envelope. Their value is analyzability: any admitted behavior must still project its triggers, dependencies, actions, and resource claims into the contract surface of Definition 1 and the composition dimensions of Definition 2. Declarative growth therefore comes from widening orthogonal dimensions; behaviors outside that envelope arrive as authored artifacts under the same contract.

2.5

AI-Mediated Authoring

A marketplace can accumulate extensions from many authors, but it cannot cover the full long tail of Section 1. FFH therefore extends openness from third-party publication to end-user commissioning: when retrieval misses, the system may create on the user’s behalf, but the result still enters through the same admission path as any other extension. FFH selects among three tiers using two predicates: whether the needed engine is already available (𝐺), and whether the requested behavior is expressible as a zero-logic specification over existing contracts and APIs (𝑍 ). If 𝐺 ∧ 𝑍 , the request is Tier 1; if 𝐺 ∧ ¬𝑍 , Tier 2; if ¬𝐺, Tier 3. The lowest sufficient tier always wins. Before tier selection, FFH returns unsupported if the device lacks the needed capability and unauthorable if the request requires a platform declaration the harness does not possess. The tiers correspond to three artifact classes. Tier 1 is a zerologic specification, i.e., a point in the five-dimensional composition space of Section 2.4. Tier 2 is restricted script executed inside the harness sandbox over engines already present on the device. Tier 3 introduces native capability not already available inside the harness, as a package that implements an existing contract, adds a tool under an admitted generic contract, or supplies a new engine. The on-device agent is the requester, validator, and final acceptor; the Web coding agent is an off-device commissioned developer; and the marketplace is the retrieval and publication substrate. Validation occurs where the artifact’s runtime can exist and fail reversibly: Tier 1 and Tier 2 are validated entirely on device, whereas Tier 3 additionally passes through a cloud test base of disposable runtimes. Final admission remains device-local. Validation certifies admissibility, not semantic perfection: machine checks establish contract conformance and trial safety, while semantic fit is judged by the user on the running artifact. For Tier 1 and Tier 2, the order is render → accept → admit. Tier 3 instead uses bounded post-install trial on Android: after a green cloud report, the device installs the package transactionally, records a trial deadline, and retains it only if the user accepts; refusal or expiry rolls it back. For replacement, where rollback would discard the incumbent, confirmation is requested before the transaction. Operationally, FFH is retrieval-first: it first searches the marketplace and commissions the Web coding agent only on a miss, using a brief derived from the intent, schema, rules, and templates. Candidate artifacts iterate through tier-appropriate validation until one is admitted or the request is rejected. Publication back to the marketplace is optional and grants no exemption: later downloads traverse the same admission pipeline, minus generation. This keeps commissioned authoring bounded by existing contracts and preserves the no-bypass admission rule.

3

Android Realization

FFH separates frozen mechanism from mutable membership, and the Android realization preserves this split as a deployment boundary. The base that makes plugins loadable, checkable, and runnable ships in the APK, while plugin implementations arrive as signed packages and can change at runtime. Thus, any capability expressible by the frozen contracts evolves through replaceable packages rather than APK updates. This is the concrete form of FFH’s central claim: the

Bo Zhang, Pengbo Zhang, Jiaxin Jiao, and Yue Liu

cloud · never hosts production FFH distribution service

test base

creation-agent endpoint

packages enter market

up: publish · creation task

market · mutable membership L1 required bundle down: index · artifact · report

L2 free packages pull · retrieve · install

device (APK) · frozen base L0 kernel · frozen

assembly layer · installer

market client · only door

are checked before load, the device consults a signature index with revocation state, and users may additionally pin creator identities directly. Admission remains device-local and fails closed when the required trust evidence is unavailable. Once a package has been admitted, execution remains offline-capable from the admitted snapshot; trust checks gate membership change rather than steady-state execution. For native artifacts, installation is identity-bound, reverified at load time, and retained only after durable acceptance.

3.2 Figure 3: Deployment boundary. The frozen base ships in the APK, mutable membership flows through the market, and the cloud provides only supporting services for distribution, Tier-3 verification, and commissioned creation. Production execution and final admission remain device-local. harness stays fixed where trust and continuity concentrate, while capability evolves through replaceable membership. On Android, this split yields three administrative domains (Figure 3). The device is the only production runtime: it hosts the 𝐿0 kernel, the assembly layer, and the built-in market client, and it is the only place where final admission is decided. The market carries mutable membership, including the 𝐿1 bootstrap set and all 𝐿2 extensions. The cloud provides only supporting services: package distribution, the Tier-3 test base, and the commissioned-authoring endpoint. It never hosts a production harness. This split makes execution device-local and evolution package-based, and the rest of this section shows how Android realizes that boundary.

3.1

Frozen Base and Mutable Membership

The APK ships mechanism, not evolving end-user capability. It contains the 𝐿0 kernel, the assembly layer that installs and binds plugins, and the built-in market client that bootstraps mutable membership. The kernel provides the registry, lifecycle machinery, event-log semantics, contract library, and validation rules. The assembly layer handles manifest adjudication, loading, signature checks, contract registration, and the host UI shell. The market client must ship in the APK because the device needs a bootstrap channel to retrieve packages that are not yet present locally. Two invariants govern the APK. First, the empty-socket invariant: the APK ships contracts and mechanism, but no evolving domain-capability implementations. Second, the frozen-surface invariant: contract signatures, manifest and log formats, and rule assets change only with an APK release. Together, these invariants make the APK a stable execution substrate rather than a carrier of changing end-user capability. Mutable membership flows through the market. The 𝐿1 bootstrap set supplies the required roles that complete the harness after installation, while 𝐿2 contains optional extensions. Operationally, 𝐿2 artifacts may be added or removed freely, whereas 𝐿1 artifacts are admitted only as same-function replacements under stricter verification, including re-checks of the replaced role’s constraints. All market packages share one envelope: identity, signature, dependency declarations, and a typed payload. Payloads may be declarative specifications, sandboxed scripts, or native dex packages. Trust is layered rather than centralized: creator signatures

Cloud Support Services

The cloud is the only administrative domain that never hosts a production harness. Its role is deliberately narrow: it supports distribution and creation, but does not participate in steady-state execution or final admission. It provides three services. The distribution service stores market packages and publishes trust metadata such as the signature index and revocation state. The test base is used only for Tier-3 artifacts, running candidate native packages in disposable Android runtimes before they may be delivered to a device. The creation-agent endpoint serves commissioned authoring requests as bounded tasks rather than as an interactive remote runtime. Because the cloud supports only distribution and creation, the device remains offline-capable for local lifecycle operations once packages have been retrieved and admitted. Connectivity is required only for inherently remote tasks such as fetching packages, consulting remote trust state, or commissioning new artifacts.

3.3

Device-Local Runtime and Admission

To host a changing plugin set above a frozen base, FFH keeps recovery, membership change, and admission coherent under process death and replacement through three device-local mechanisms. Replay-based recovery. On cold start, the device reconstructs runtime state by replaying the event log against the installed membership; the log remains authoritative across process death, including the write-ahead trigger registrations of Section 2.3. Transactional membership change. Installation, replacement, and removal are realized as manifest transactions. A transaction validates the new membership, prepares the change, and rolls back on failure before the old state is irreversibly released. Dependents therefore suspend rather than error, and a partially withdrawn membership state is never exposed. Uniform admission pipeline. Every artifact that introduces a new behavior passes through the same admission ladder: static checks, a tier-appropriate trial where the runtime permits one, and user acceptance on the running artifact. Replacing an 𝐿1 implementation additionally re-runs the replaced role’s constraint suite before commit. Tier 1 and Tier 2 artifacts are validated entirely on device; Tier 3 additionally requires a green report from the cloud test base before bounded on-device trial and final acceptance. These mechanisms are the implementation counterpart of Section 2. Continuity, membership change, and final trust remain anchored on device even though publication, retrieval, and commissioned authoring are open.

4

Evaluation

We evaluate FFH as an architecture for open and composable mobile extensions on the Android prototype of §3. All experiments run on

FreeForm Harness

a Xiaomi 14 Pro under Android 16 with the live cloud services of §3. Our goal is not to benchmark a particular coding model, but to test whether FFH (i) enforces its claimed guarantees under open extension, (ii) covers a broader and more stable reactive-mobile composition class than simpler automation abstractions, (iii) closes the loop from user intent to admitted on-device behavior, and (iv) does so at bounded mobile cost. Workload and baselines. We construct a 50-case benchmark of reactive-mobile requests from anonymized daily-life requests and public trigger-action recipes [13, 14]. Cases are included only when they admit a concrete delivery oracle; explicit unsupported, unauthorable, and principled-refusal cases are also included so that honest non-closure is measured rather than hidden. Principled nonadmission is therefore counted as honest non-closure, not as silent failure, since FFH claims bounded openness under device-local admission rather than unconditional closure. We compare FFH-full against three baseline families: internal weakened variants, which remove one guarantee-enforcing mechanism while holding the rest of the harness fixed; pipeline baselines, which remove one openness stage such as commissioned authoring, preview, or device-local final acceptance; and an automation baseline, a concrete recipestyle trigger-condition-action substrate over the same device and delivery oracles. The automation baseline provides a fixed workflow schema with recipe-scoped and shared state, plus bounded inline scripting, but lacks reusable providers, shared durable log queries, first-class slot or asset dimensions, same-function replacement, commissioned authoring, and device-local admission.

4.1

Architectural Guarantees and Necessity

We test whether FFH enforces the guarantees motivating its required layer and uniform contract: safe assembly, mediated boundaries, coherent dependency handling and replacement, transactional membership change, single-source location, durable triggering, single-holder arbitration, and the frozen-surface split (Table 4). FFH-full enforced all tested contract boundaries. Malformed artifacts were rejected before activation, conforming controls were admitted, mediated over-reach was refused, required-provider removals suspended dependents crash-free, optional-provider removals fell back to declared defaults, provider replacements rebound through the live registry, and unload left no residue in harness-owned state. Interrupted installs rolled back cleanly, and audited turns matched the independently specified log projection. These results show FFH’s contract is operational rather than merely descriptive. The required authorities likewise preserved their invariants. Location remained single-source and lease-governed under concurrent consumers; write-ahead reconciliation preserved trigger commitments across kill–restart; and the arbiter preserved single-holder behavior under contention and injected OS seizure. A released-package audit found no frozen-surface split violation: the APK contained no undeclared domain capability, 𝐿1 uninstalls were refused, bootstrap recovery succeeded after data wipe, and same-function substitutions passed their re-run constraint suites. The weakened variants show that these properties do not survive removal of the corresponding mechanisms. Disabling host-tracked rebinding and reversible cleanup produced stale bindings and residual harness state. Removing write-ahead reconciliation produced

Table 2: Benchmark-level comparison. Metric Representable Direct / workaround / not repr. Closure / honest non-closure

FFH

Automation

50 50 / 0 / 0 44 / 6

38 15 / 23 / 12 17 / —

orphaned handles and missing re-established registrations after kill–restart. Replacing required authorities with plugin-local besteffort coordination lost single-source location semantics and singleholder resource behavior. Taken together, these results support the architectural claim that FFH’s guarantees come from its contract and required authorities, not merely from having plugins.

4.2

Composition Coverage and Comparative Expressiveness

We next ask whether FFH’s declared composition envelope is broad enough to matter and broader than a simpler recipe abstraction. We evaluate three properties: adequacy, stability, and comparative expressiveness against the automation baseline. All 50 benchmark cases projected into FFH’s five-dimensional composition space without requiring a new dimension. Coverage was not confined to a narrow corner of the model: 23 cases involved location or mobility, all 50 involved proactive triggering, and all 50 touched at least one scarce presentation channel or other exclusive resource. The benchmark also includes multi-step coordinated actions, durable state suppression, guarded multi-source joins, retrieval-ambiguous and preview-sensitive requests, and principled non-closure cases. The interpreter audit found no case that required widening the declared composition space by editing an existing interpreter. Table 2 summarizes the benchmark-level comparison, and Table 5 in Appendix B records the fuller probe ledger behind these aggregates. FFH represented all 50 benchmark cases within its declared composition envelope and closed 44/50 end to end, with the remaining six terminating honestly as unsupported, unauthorable, or principled-refusal outcomes. The automation baseline represented 38/50 cases in total—15 directly, 23 only through workarounds, and 12 not at all without adding a new capability class—and closed only 17/50 under the same delivery oracles. The difference is therefore operational as well as representational: workaround-based realizations were often too fragile or non-portable to satisfy the benchmark’s admitted execution criteria. The main deficits of the automation baseline were log-derived absence checks, guarded multi-source joins, slot-aware delivery, asset-bound behavior, and multi-step or stateful fallback behavior. We also tested substitution stability as same-function replacement over ten L1 slots with three implementations each, plus six tuples violating the declared surface. Across the 36 substitutions, FFH realized 30 admissible variants without interpreter modification and correctly refused six forbidden tuples under the declared constraints or interpreter envelope. The automation baseline was local in only 3/36 analogous substitutions; the remainder required workflow rewrites, duplicated recipes, or were unsupported. Within the studied reactive-mobile class, FFH therefore behaves as a stable composition envelope rather than a collection of hardwired cases.

Bo Zhang, Pengbo Zhang, Jiaxin Jiao, and Yue Liu

4.3

End-to-End Openness

We evaluate FFH’s openness claim as an end-to-end workflow from user intent to admitted on-device behavior. For each benchmark case, FFH first attempts retrieval from the marketplace; on a miss, it selects an authoring tier, commissions the Web coding agent if needed, validates the returned artifact, previews it in the tierappropriate order, and admits it on device. We compare FFH-full against three pipeline baselines: retrieval-only, author-withoutpreview, and author-without-device-local-final-admission. At the benchmark level, FFH closed 44/50 cases end to end, as summarized in Table 2. Retrieval closed 17 cases directly; 27 cases entered commissioning; and six cases terminated honestly before artifact production, spanning unsupported, unauthorable, and principled-refusal outcomes. Within the commissioned set, four cases were routed to Tier 1, 22 to Tier 2, and one to Tier 3. All 27 commissioned cases reached admission and executed successfully in the main benchmark run. Revision burden remained bounded (mean 1.4, median 1, max 3), and preview rejected four machine-valid artifacts that were then revised once and admitted. These results show that FFH’s openness is not reducible to reuse alone. Retrieval-only closed only the 17 reuse hits, while retrievalambiguous cases still required preview-mediated disambiguation or commissioned refinement. Without preview, four machine-valid but semantically rejected artifacts would have been admitted; without device-local final acceptance, they would have become active without a final trust decision on device. Against the automation baseline, which closed only 17/50 cases, FFH’s pipeline therefore expands closure beyond recipe-only automation. To test robustness beyond a single clean pass, we re-ran a 10-case commissioned subset five times each under the same coding-agent configuration. Across 50 runs, 46 reached admission and successful execution (92%), with mean revision count 1.6, stable tier routing in 48/50, and only limited intervention: 7/50 runs required one standardized restatement of intent, with no artifact editing, prompt patching, or validation override. These results do not establish robustness across arbitrary models or prompts, but they show that FFH’s openness pipeline is not a one-shot artifact of a lucky run and provide strongest evidence for Tier 1 and Tier 2 closure, with Tier 3 demonstrated only at feasibility level.

4.4

Cost, Tradeoffs, and Limitations

FFH’s guarantees are not free, so we measure whether they come at bounded rather than mobile-prohibitive cost. On the studied prototype, cold start completed in 380 ms median, replay-based recovery bounded above by 505 ms, install in 178 ms, replacement in 335 ms, and unload in 19 ms. Trigger-to-action latency remained bounded at 1.7 ms median for periodic and event-triggered delivery and 0.2 ms for geofence-triggered reminders, within the warm process (wake-path costs excluded). Over an eight-hour mixed-trigger run, FFH-full consumed 4.1% battery, against 3.5% for the fully weakened variant and 3.2% for the automation baseline. Thus FFH’s stronger guarantees come at measurable but bounded cost. The evaluation has several limits. The benchmark is broad but not exhaustive; Tier 3 engine requests are underrepresented; the openness results depend in part on the commissioned coding agent; all measurements were taken on one device model; and we report

neither a longitudinal non-programmer study nor an adversarial publisher study. Our fail-closed claim is correspondingly narrow: when the loop does not close before admission, FFH rejects, revises, or returns a structured non-admission outcome rather than admitting unchecked behavior.

5

Related Work

FFH relates to four nearby lines of work: mobile agents, pluginbased agent substrates, end-user automation and skill reuse, and mobile automation ecosystems with third-party extensions. Mobile GUI agents such as AppAgent [22], CogAgent [3], the Mobile-Agent line [16, 18], and MobiAgent [20] demonstrate increasingly capable mobile-native interaction, but package capability inside end-to-end pipelines rather than as externally installable runtime components. More system-oriented platforms such as AIOS [8], UFO3 [21], Aura [23], and NLAH [10] move closer to modularity or registry-based management, but do not establish FFH’s combination of frozen contracts, mutable plugin membership, device-local admission, and end-user facing openness for mobile extensions. DeepSeek Harness and Cordis [11] are FFH’s closest architectural precursors: they show that agents can be organized as plugin substrates with externalized manifests and contract-mediated interoperability. FFH extends this line to mobile execution through a permanence-aware split between frozen base and mutable membership, required-layer absorption of mobile-native constraints, and device-local admission. FFH also differs from prior work on reusable skills, trigger-action automation, composition, location grounding, and mobile automation ecosystems with plugin markets [1, 2, 4–7, 9, 12–15, 17, 19]. These lines show that behaviors can accumulate, be recombined, and sometimes be authored or installed by non-programmers, but not as a mobile-native harness that simultaneously provides a uniform declarative contract, open runtime installation and replacement, a permanence-aware required layer for location, triggering, and scarce-resource control, device-local admission, and a unified path from third-party publication to end-user commissioning. FFH is therefore not simply another mobile assistant or automation tool, but a Web infrastructure substrate for carrying open publication and composition to on-device agent execution. Appendix C summarizes the capability-level comparison.

6

Conclusion

This paper argues that openness on mobile is fundamentally an architectural problem. FFH addresses it by separating what must persist from what should remain open: a frozen base and permanenceaware required layer provide the guarantees mobile execution cannot leave to chance, while a uniform contract keeps extensions composable and replaceable above them. Our Android realization and evaluation show that these boundaries are enforceable in the running system, that the declared composition model covers realistic daily-life requests without widening, and that the extension pipeline closes from user intent to admitted on-device behavior while final trust remains device-local. More broadly, FFH extends the plugin-substrate line of DeepSeek Harness and Cordis [11] to the mobile agentic-Web setting. We hope it can serve as a reference point for agent harnesses that remain frozen where trust concentrates and fluid where creativity belongs.

FreeForm Harness

References [1] Jiaqi Chen, Bingqian Lin, Ran Xu, Zhenhua Chai, Xiaodan Liang, and Kwan-Yee Wong. 2024. MapGPT: Map-Guided Prompting with Adaptive Path Planning for Vision-and-Language Navigation. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 9796–9810. [2] Kevin Ellis, Lionel Wong, Maxwell Nye, Mathias Sablé-Meyer, Luc Cary, Lore Anaya Pozo, Luke Hewitt, Armando Solar-Lezama, and Joshua B Tenenbaum. 2023. DreamCoder: growing generalizable, interpretable knowledge with wake– sleep Bayesian program learning. Philosophical Transactions of the Royal Society A 381, 2251 (2023), 20220050. [3] Wenyi Hong, Weihan Wang, Qingsong Lv, Jiazheng Xu, Wenmeng Yu, Junhui Ji, Yan Wang, Zihan Wang, Yuxiao Dong, Ming Ding, et al. 2024. CogAgent: A Visual Language Model for GUI Agents. In 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). IEEE, 14281–14290. [4] Sehoon Kim, Suhong Moon, Ryan Tabrizi, Nicholas Lee, Michael W Mahoney, Kurt Keutzer, and Amir Gholami. 2023. An LLM Compiler for Parallel Function Calling. arXiv preprint arXiv:2312.04511 (2023). [5] Hao Li, Chunjiang Mu, Jianhao Chen, Siyue Ren, Zhiyao Cui, Yiqun Zhang, Lei Bai, and Shuyue Hu. 2026. Organizing, Orchestrating, and Benchmarking Agent Skills at Ecosystem Scale. arXiv preprint arXiv:2603.02176 (2026). [6] Toby Jia-Jun Li, Marissa Radensky, Justin Jia, Kirielle Singarajah, Tom M Mitchell, and Brad A Myers. 2019. PUMICE: A Multi-Modal Agent that Learns Concepts and Conditionals from Natural Language and Demonstrations. In Proceedings of the 32nd Annual ACM Symposium on User Interface Software and Technology. 577–589. [7] Rohin Manvi, Samar Khanna, Gengchen Mai, Marshall Burke, David Lobell, and Stefano Ermon. 2024. GeoLLM: Extracting Geospatial Knowledge from Large Language Models. In International Conference on Learning Representations. [8] Kai Mei, Xi Zhu, Wujiang Xu, Wenyue Hua, Mingyu Jin, Zelong Li, Shuyuan Xu, Ruosong Ye, Yingqiang Ge, and Yongfeng Zhang. 2024. AIOS: LLM Agent Operating System. arXiv preprint arXiv:2403.16971 (2024). [9] Yansong Ning, Shuowei Cai, Wei Li, Jun Fang, Naiqiang Tan, Hua Chai, and Hao Liu. 2025. DiMA: An LLM-Powered Ride-Hailing Assistant at DiDi. In Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V. 2. 4728–4739. [10] Linyue Pan, Lexiao Zou, Shuo Guo, Jingchen Ni, and Hai-Tao Zheng. 2026. Natural-Language Agent Harnesses. arXiv preprint arXiv:2603.25723 (2026). [11] Yifan Shi, Wei Zhang, and Tianyi Cui. 2026. A Programming Paradigm for Spatiotemporal Composability. arXiv preprint arXiv:2608.25512 (2026). [12] Richard S Sutton, Doina Precup, and Satinder Singh. 1999. Between MDPs and semi-MDPs: A framework for temporal abstraction in reinforcement learning. Artificial Intelligence 112, 1–2 (1999), 181–211. [13] Blase Ur, Elyse McManus, Melwyn Pak Yong Ho, and Michael L Littman. 2014. Practical Trigger-Action Programming in the Smart Home. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. 803–812. [14] Blase Ur, Melwyn Pak Yong Ho, Stephen Brawner, Jiyun Lee, Sarah Mennicken, Noah Picard, Diane Schulze, and Michael L Littman. 2016. Trigger-Action Programming in the Wild: An Analysis of 200,000 IFTTT Recipes. In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems. 3227–3231. [15] Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. 2023. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv preprint arXiv:2305.16291 (2023). [16] Junyang Wang, Haiyang Xu, Haitao Jia, Xi Zhang, Ming Yan, Weizhou Shen, Ji Zhang, Fei Huang, and Jitao Sang. 2024. Mobile-Agent-v2: Mobile Device Operation Assistant with Effective Navigation via Multi-Agent Collaboration. Advances in Neural Information Processing Systems 37 (2024), 2686–2710. [17] Zhiyong Wu, Chengcheng Han, Zichen Ding, Zhenmin Weng, Zhoumianze Liu, Shunyu Yao, Tao Yu, and Lingpeng Kong. 2024. OS-Copilot: Towards Generalist Computer Agents with Self-Improvement. arXiv preprint arXiv:2402.07456 (2024). [18] Haiyang Xu, Xi Zhang, Haowei Liu, Junyang Wang, Zhaozai Zhu, Shengjie Zhou, Xuhao Hu, Feiyu Gao, Junjie Cao, Zihua Wang, et al. 2026. Mobile-Agent-v3.5: Multi-platform Fundamental GUI Agents. arXiv preprint arXiv:2602.16855 (2026). [19] Bufang Yang, Lilin Xu, Liekang Zeng, Kaiwei Liu, Siyang Jiang, Wenrui Lu, Hongkai Chen, Xiaofan Jiang, Guoliang Xing, and Zhenyu Yan. 2025. ContextAgent: Context-Aware Proactive LLM Agents with Open-World Sensory Perceptions. Advances in Neural Information Processing Systems 38 (2025), 185637– 185671. [20] Cheng Zhang, Erhu Feng, Xi Zhao, Yisheng Zhao, Wangbo Gong, Jiahui Sun, Dong Du, Zhichao Hua, Yubin Xia, and Haibo Chen. 2025. MobiAgent: A Systematic Framework for Customizable Mobile Agents. arXiv preprint arXiv:2509.00531 (2025). [21] Chaoyun Zhang, Liqun Li, He Huang, Chiming Ni, Bo Qiao, Si Qin, Yu Kang, Minghua Ma, Qingwei Lin, Saravan Rajmohan, et al. 2025. UFO3: Weaving the Digital Agent Galaxy. arXiv preprint arXiv:2511.11332 (2025). [22] Chi Zhang, Zhao Yang, Jiaxuan Liu, Yanda Li, Yucheng Han, Xin Chen, Zebiao Huang, Bin Fu, and Gang Yu. 2025. AppAgent: Multimodal Agents as Smartphone Users. In Proceedings of the 2025 CHI Conference on Human Factors in Computing

Systems. 1–20. [23] Zhenhua Zou, Sheng Guo, Qiuyang Zhan, Lepeng Zhao, Shuo Li, Qi Li, Ke Xu, Mingwei Xu, and Zhuotao Liu. 2026. Blind Gods and Broken Screens: Architecting a Secure, Intent-Centric Mobile Agent Operating System. arXiv preprint arXiv:2602.10915 (2026).

A

Complete Layer Membership

Table 3 is the concrete witness for the partition claim of Section 2.1. It lists every catalogued 𝐿0 member and every required 𝐿1 role together with the criterion or wing that places it there and the consequence of its absence. Assembly mechanisms that are nonplugin by construction, including market intake validation, belong to K and are therefore not repeated as plugin rows here. The builtin market client is the one 𝐿1 role that ships inside the APK rather than through the bootstrap set. Membership is recorded per assembly row, but permanence in 𝐿1 attaches to the required role rather than to any one implementation. Same-function replacement must therefore preserve the service keys and guarantees that justify the role’s membership in 𝐿1 . The open remainder 𝐿2 is not enumerated. No 𝐿1 member satisfies an 𝐿0 criterion: removing any one degrades the agent’s guarantees, but does not prevent the plugin system itself from booting or interpreting declarations. Conversely, the eight 𝐿0 rows are exactly the bootstrapping and semantically unique elements that define the harness. The partition is therefore witnessed by eight 𝐿0 members, the required 𝐿1 roles above, and the open remainder 𝐿2 .

B

Evaluation Detail Summary

This appendix records the minimum detail needed to interpret Section 4. In the main text, Table 2 summarizes the benchmark-level comparison between FFH and the automation baseline. Here we separate the appendix evidence by evaluation question rather than collapsing all results into one ledger. Table 4 records the probe families and ablation outcomes behind the architectural guarantees and necessity claims of §4.1. Table 5 then summarizes the benchmark and closure outcomes used for composition and openness, together with the robustness statistics reported in the main text. More specifically, Table 4 corresponds to §4.1; the Composition rows of Table 5 complement the benchmark-level comparison reported in Table 2 of §4.2; and the Openness rows of Table 5 correspond to §4.3, including the retrieval-first openness path and the pipeline baselines used to isolate the contribution of commissioning, preview, and device-local final acceptance. The appendix tables are intended as compact audit trails for the headline numbers in the main paper rather than as replacements for the narrative interpretation there. Table 4 should be read row-wise. The Guarantees rows correspond directly to the properties claimed in §4.1: safe assembly, mediated boundaries, coherent dependency handling and replacement, transactional membership change, single-source location and durable triggering, single-holder arbitration, and the frozen-surface split. The Ablation rows then record the weakened variants used to support the necessity argument. Taken together, these rows make explicit that the guarantees reported in the main text are not merely descriptive properties of one implementation snapshot: they are

Bo Zhang, Pengbo Zhang, Jiaxin Jiao, and Yue Liu

Table 3: Complete layer membership witness for the partition of Section 2.1. Row ID

Member

Criterion / wing

Consequence of absence

kernel.plugin kernel.declare

Plugin system kernel Contract declaration primitives Runtime environment contract

Bootstrapping Bootstrapping

No plugin can be registered, scheduled, or resolved Plugins cannot interpret each other’s declarations

Bootstrapping + semantic uniqueness Bootstrapping

No uniform mediated runtime surface for execution

kernel.runtime

kernel.log

Lifecycle fault isolation Event-log semantics

kernel.invariants

Invariant registry

kernel.contracts

Contract library

kernel.rules

Rule-asset catalog

agent.loop effect.arbiter exec.wrapper log.writer credential.vault llm.route permission.portal foreground.lifecycle arbiter.voice arbiter.location

Agent loop Effect arbitration Execution wrapper Event-log writer Credential vault LLM routing Permission portal Foreground lifecycle Voice-channel lease Location subscription lease Camera lease Notification-slot lease Multi-lease transaction broker Memory store Fault notification Tool registry Session service UI registry Recovery coordinator Task state machine and artifact review Retention erasure Platform state portal Request intake Location source Background wakeup Egress adjudication Consent ledger Requirement assembler Human-interaction channel Model provider Built-in market client

kernel.faults

arbiter.camera arbiter.notification arbiter.transaction memory.store fault.notify tool.registry session.service ui.registry recovery.coord creation.task retention.erase platform.state intake.dispatcher location.source wakeup.background egress.gate consent.ledger requirement.assemble human.channel model.provider market.channel

One faulty install or stop can crash the whole process

Semantic uniqueness Bootstrapping + semantic uniqueness Semantic uniqueness Semantic uniqueness

No durable, replayable truth for recovery or audit

authoring safety continuity continuity safety safety safety continuity safety safety

No turn executes; serving and authoring both stop Write effects execute without user adjudication Calls run unbounded and uncancellable State is not durably written across process death Keys and tokens lack a single protected entry point Model egress and cost lack a single adjudication point Grants occur without a user-facing portal Foreground presence and managed liveness are lost Exclusive audio is held without arbitration Exclusive location subscription is held without arbitration

safety safety safety

Exclusive camera access is held without arbitration The presentation slot has no single holder Multi-resource claims cannot be acquired all-or-nothing

continuity safety authoring authoring authoring authoring safety + authoring safety continuity authoring continuity continuity safety safety authoring

Persistent memory tools and cross-turn facts are lost Failures occur without user awareness Capabilities cannot be declared as tools to the loop No session or derived views exist for interaction No slots exist for credential entry or permission grants Incomplete turns are not recovered before progress Commissioned authoring lacks lifecycle and artifact adjudication Deleted data may revive against policy Platform facts lack a unique source Arrivals drop without acceptance or logging Location facts lack a unique producer Declared conditions cannot revive the process Data egress lacks adjudication Consent facts are not durably recorded Commissioned authoring cannot form a self-contained brief

authoring

Intents and confirmations lack a path

authoring authoring

No completion path exists for intent understanding Packages cannot be retrieved or published

Invariants are neither registered nor checked No frozen socket vocabulary for cross-plugin collaboration Validation rules are absent at admission

enforced under direct probes and fail in characteristic ways when the corresponding mechanism is removed. Table 5 should be read row-wise. The Composition block summarizes the benchmark-level evidence for composition coverage and comparative expressiveness, complementing the main-text comparison of Table 2 with the automation-baseline breakdown into direct, workaround, and non-representable cases. The Openness block summarizes the retrieval-first openness pipeline, including retrieval, commissioning, honest non-closure, the three pipeline baselines, preview rejection, repeated-generation robustness, and bounded researcher intervention.

Architectural guarantees and necessity. It should be read as the appendix counterpart of §4.1. The first seven rows record direct enforcement probes on FFH-full. These rows correspond to the contract and runtime properties claimed in the main text: malformed artifacts are rejected before activation; conforming controls are admitted; mediated over-reach is refused; required-provider absence suspends dependents rather than crashing them; replacement and unload preserve registry coherence; interrupted installs roll back cleanly; and the required authorities preserve single-source location, durable triggering, and single-holder arbitration under perturbation. The final three rows record the weakened variants

FreeForm Harness

Table 4: Architectural guarantees and necessity: enforcement probes and weakened-variant outcomes. Trial counts are not comparable across the two blocks: Guarantees rows count probe scenarios, Ablation rows randomized trials. Part

Property / question

Probe family

Count / setup

Outcome

Guarantees

Malformed artifacts / conforming controls Over-reach attempts

14 / 4

Guarantees

Safe assembly and contract admission Mediated contract boundary

Guarantees

Coherent dependency handling

Guarantees

Coherent replacement and unload Transactional membership change and auditability Single-source location, durable triggering, and single-holder arbitration

Required / optional removals Provider replacements / unload trials Interrupted installs / audited turns Location / trigger / arbiter probes

All malformed artifacts were rejected before activation; all conforming controls were admitted All mediated over-reach attempts were refused at the declared boundary Required-provider absence suspended dependents without crash; optional-provider absence took declared defaults Live-registry rebinding was preserved; unload left an empty diff over harness-owned state All interrupted installs rolled back cleanly; model-visible context matched the independently specified log projection Single-source location, durable trigger recovery, and single-holder arbitration were preserved under the corresponding perturbations

Guarantees Guarantees

6 10 / 10 5 / 20 10 / 20 8 consumers / 30 kill points / 24+30+10 contention trials 30 uninstall attempts + 3 wipes + 5 substitutions

Guarantees

Frozen-surface split and required-role permanence

Released-package audit

Ablation

Necessity of host-tracked rebinding and reversible cleanup Necessity of write-ahead reconciliation Necessity of required authorities

No rebinding / cleanup

20 trials

No write-ahead reconciliation No required authorities

30 kill–restart trials

Produced failures in 17/20 trials: 14 stale-binding and 3 residual-state; the remaining 3 trials showed neither. The stale/residual split reflects the trial mix, not mechanism strength. Produced 12 reconciliation mismatches after kill–restart

1/2/4/8 consumers; 120+120 contention/race trials

Lost normalized single-source location semantics: the broker kept a single holder in 120/120 trials, whereas per-block acquisition split in 90/120, granted partial sets in 120/120, and let 480 foreign writes onto the bus

Ablation Ablation

used for the necessity argument. Their role is not to define alternative deployment targets, but to show that the reported guarantees do not survive removal of the corresponding mechanism. Automation baseline. The automation baseline is defined in Section 4 as the recipe-style trigger-condition-action substrate against which FFH’s composition coverage and end-to-end closure are compared. As reflected in Table 2 and Table 5, the benchmark includes cases that exercise retrieval ambiguity, multi-step coordinated actions, durable state suppression, guarded multi-source joins, stateful fallback behavior, and principled non-closure. The comparison should therefore be read as a benchmark over a broader reactivemobile class rather than as a narrow reminder-only comparison. Pipeline baselines. The pipeline baselines summarized in the Openness rows of Table 5 isolate the contribution of individual stages in the retrieval-first openness path of §4.3. The retrievalonly baseline disables commissioned authoring and therefore tests how far reuse alone can close the benchmark. The author-withoutpreview baseline removes the semantic-fit gate provided by user preview, exposing the cases in which machine-valid artifacts would still have been unacceptable as rendered behavior. The author-withoutdevice-local-final-admission baseline removes the final device-local acceptance step, exposing the cases in which artifacts would have become active without a final trust decision on the user’s device. These baselines are not intended as deployment targets; they are stage-removal comparators showing that the openness pipeline’s intermediate gates are substantive, not ceremonial. Openness protocol notes. The openness results of Section 4.3 should be read with two scope conditions in mind. First, researcher intervention was bounded: at most one standardized restatement

No undeclared domain capability appeared in the APK; 𝐿1 uninstall was refused; bootstrap recovery and same-function substitution were preserved

of the original intent was permitted per case, and no artifact editing, prompt patching, or validation override was allowed. Second, the evidence is strongest for Tier 1 and Tier 2 closure. Tier 3 is represented by a single benchmark case and therefore supports a feasibility claim for native-package introduction rather than a broad coverage claim over the Tier 3 design space. Cost measurement setup. The cost numbers of Section 4.4 are not repeated here; the tables instead record the context in which they should be read. Cold start and replay-based recovery were measured from process launch to reconstructed steady state. Membershipchange latency was measured for install and replacement from activation to the manifest commit, and for unload from the committed removal to disposal. Trigger-to-action latency was measured end to end within the warm process (wake-path costs excluded) for periodic, event-triggered, and geofence-triggered cases. Memory and storage measurements on a debug build report 142 MB PSS after startup (306 MB RSS), a mean per-plugin increase of 0.98 MB, event-log growth of 0.23 MB per 1,000 events, and 0.73 MB of manifests and packaged rule assets for the shipped assembly, excluding optional market packages. Medians are computed over repeated runs, with p95 or a worst-case bound reported where repeated samples exist.

C

Capability-Level Comparison

Table 6 scopes the comparison claims of Section 5 to properties publicly demonstrated in the cited sources. It is not a ranking of overall system quality. “Not demonstrated” denotes absence of public evidence for the listed property, not a claim of impossibility.

Bo Zhang, Pengbo Zhang, Jiaxin Jiao, and Yue Liu

Table 5: Composition and openness ledger: benchmark outcomes, pipeline baselines, and robustness. Part

Item

Count / value

Result

Composition

Benchmark cases

50

Composition Composition

FFH representability Benchmark-level comparison

Composition

Automation baseline

Composition

Substitution tests

50/50 FFH: 50 representable, 44 closed, 6 honest non-closures; Automation: 38 representable, 17 closed 15 direct / 23 workaround / 12 not representable 36

All admit concrete delivery oracles; 23 involve location/mobility; all 50 involve proactive triggering and at least one scarce channel/resource All cases fit the five-dimensional composition space; no interpreter widening required FFH represented all benchmark cases and closed substantially more of them end to end; the automation baseline relied heavily on workarounds and left 12 cases outside its declared abstraction

Openness

17 / 27 / 6

Openness

Retrieval / commissioning / honest pre-termination Honest pre-terminations

Openness Openness Openness

Tier routing Main-run closure Pipeline baseline: retrieval-only

4 / 22 / 1 44/50 17/50

Openness

4 affected cases

Openness

Pipeline baseline: author-without-preview Pipeline baseline: author-withoutdevice-local-final-admission Preview rejections / revision burden

Openness

Repeated-generation robustness

4 / mean 1.4, median 1, max 3 46/50

Openness

Researcher restatements

7/50

Openness

6

4 affected cases

Only 17/50 closed end to end under the same delivery oracles; main deficits were log-derived absence checks, guarded multi-source joins, slot-aware delivery, asset-bound behavior, and multi-step or stateful fallback behavior FFH realized 30 admissible variants and refused 6 forbidden tuples; automation baseline was local in 3/36 only Retrieval closed 17; 27 entered commissioning; 6 terminated honestly before artifact production Unsupported, unauthorable, and principled-refusal outcomes before artifact production Tier 1 / Tier 2 / Tier 3 commissioned cases All 27 commissioned cases admitted and executed successfully Closed only the reuse hits; all retrieval misses remained unresolved without commissioning Would have admitted four machine-valid but semantically rejected artifacts that preview filtered out Would have activated the same four artifacts without a final trust decision on the user’s device Four machine-valid artifacts were revised after preview rejection; benchmark includes retrieval-ambiguous, style-sensitive, and preview-dependent cases Ten commissioned cases re-run five times each; 92% repeated-run closure, mean revisions 1.6 One standardized restatement at most per case; no artifact editing, prompt patching, or override of validation/preview

Table 6: Capability-level comparison scoped to publicly demonstrated properties in the cited sources. System

FFH (this work) DSH / Cordis [11] Aura [23] NLAH [10]

AgentSkillOS [5]

Mobile-Agent-v2 / v3.5 [16, 18] AppAgent [22] MobiAgent [20]

External plugin interface

Runtime install

Mobilenative

End-user authorship

Uniform contract

Declared absence semantics

Yes Yes

Yes Yes

Yes No

Yes Yes

Yes Yes

Registrymediated No

Yes

Yes Not demonstrated

Not demonstrated No

Not demonstrated

Not demonstrated

Curated skill package interface

Yes

Not demonstrated

Not demonstrated

Not demonstrated

No

No

Yes

Yes (Tiers 1–3) Developeroriented Not demonstrated Editable policies, not plugin authorship Public contribution, not end-user commissioning No

No

No

No No

No No

Yes Yes

No No

No No

No No

Not demonstrated

Related documents

• OpenMobile-2: Building Versatile Mobile Agents with Scalable Environments and App-Native Tools#1324758
• Mobile Applications Development#1331579
• OpenMobile-2: Building Versatile Mobile Agents with Scalable Environments and App-Native Tools#1391566
• Multi-Step Tool-Calling over Korean Open Public APIs: A Benchmark and a Data-Synthesis Recipe#972321
• SchemaWeaver: Accelerating On-Device Mobile Agentic AI via Schema-Guided Parallel LLM Decoding#1342653