Skip to content

Instantly share code, notes, and snippets.

@jeremylongshore

jeremylongshore/bundled-host-sketch.md

Last active May 18, 2026 23:53
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save jeremylongshore/8e6325b6bb2b438d9fa6d8d9161c3a54 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save jeremylongshore/8e6325b6bb2b438d9fa6d8d9161c3a54 to your computer and use it in GitHub Desktop.
Download ZIP
Bundled-host architectural sketch for kobiton/automate — four named variants for AI-native experience (hybrid pattern / staging-upload / bundled host / hosted runner) with tradeoff analysis. Response to mimosa767's #53 ask 6. Decision-support, not roadmap.
Raw
bundled-host-sketch.md

Bundled-host architectural sketch — Kobiton Automate plugin

Author: Jeremy Longshore (Intent Solutions) Date: 2026-05-18 Reference: kobiton/automate#53 — mimosa767's "Reduce Claude Dependency Friction" ask, specifically Ask 6 (future product direction) Status: DRAFT — decision-support sketch, not a roadmap Related: Architectural one-pager mapping each #53 ask to L1 / L2 / L3 layer · README compatibility matrix

1. Context

#53 ask 6 raises the question: "Could portions of test generation, requirement parsing, execution orchestration, and validation feel more native within Kobiton Automate itself?" Today the strongest path runs through Claude Code with run-automation-suite, which assumes the user has a local Appium toolchain (node / python / mvn / dotnet) and a local filesystem of test scripts. That assumption is reasonable for developer-heavy teams but adds friction for tester-heavy orgs and for non-Claude-Code surfaces (Cowork install-test pending; claude.ai web, Claude Desktop, and mobile are blocked on local-FS access today).

This sketch lays out four named near-term variants that move closer to "AI-native to Kobiton" without waiting on multi-quarter MCP protocol evolution. Each variant is independently shippable; pairs are compatible (a hybrid pattern can coexist with a staging-upload tool). The point of the sketch is to make the tradeoffs visible so Kobiton can decide where to invest.

Variant 1 (hybrid pattern) was proposed by @mimosa767 in #53 comment-4482315819 and is reproduced here with credit. Variants 2-4 are Intent Solutions framings building from the same architectural starting point.

2. The four variants — one-line summaries

# Variant Who builds what Cross-client lift
1 Hybrid: local helper MCP + remote orchestration MCP Intent Solutions or community ships a small local MCP; Kobiton's existing remote MCP unchanged Helps every MCP client that supports local stdio servers
2 Staging-upload pattern Kobiton adds a pre-signed-upload endpoint + one consolidated executeTestRun MCP tool Helps every MCP client — including mobile
3 Bundled host (desktop app or polished Cowork bundle) Kobiton builds + maintains a host app or curated Cowork plugin bundle that owns the file-picker UX Helps Cowork + desktop users specifically; web/mobile via separate variants
4 Kobiton-hosted test runner Kobiton stands up server-side Appium runner with sandboxing, queue management, observability Helps every client universally; eliminates local-toolchain dependence entirely

Higher-numbered variants require less from the client. Variants 1 and 2 can be shipped in parallel; variants 3 and 4 are larger investments and benefit from variants 1 and 2 existing first. Implementation effort + scheduling for each is Kobiton's call and not estimated here.

3. Per-variant detail

3.1 Variant 1 — Hybrid pattern: local helper MCP + remote orchestration MCP

Credit: proposed by @mimosa767 in #53 comment-4482315819.

How it works. Two MCP servers, paired:

flowchart TB
    subgraph local["Local Machine (user)"]
        LM["Local helper MCP<br/>(stdio)<br/>• filesystem read<br/>• shell exec<br/>• file pickup<br/>• local Appium invoke"]
    end
    subgraph cloud["Cloud (Kobiton)"]
        RM["Remote MCP<br/>api.kobiton.com/mcp<br/>• listDevices, reserveDevice<br/>• listSessions, getSession<br/>• getSessionArtifacts<br/>• uploadAppToStore"]
    end
    CL(["Claude<br/>(any MCP client)<br/>orchestrates both"])
    CL -->|calls| LM
    CL -->|calls| RM
Loading

The local helper handles the steps that require user-machine access (reading the test script, invoking the user's installed node / python / mvn / dotnet, picking up the resulting artifacts before pushing them). The remote MCP handles everything that lives on Kobiton's side (device reservation, session lifecycle, artifact URLs). Claude orchestrates both.

What changes.

Side Change
Client User installs both MCPs. Claude Code: .mcp.json lists both. Claude Desktop: claude_desktop_config.json configures the stdio local helper alongside the existing remote Connector. Other MCP clients (Cursor, Codex CLI, etc.): per-client config
Plugin (kobiton/automate) New local-helper/ directory shipping the local MCP server as an installable npm package (or stdio binary). Existing .mcp.json config gets a second entry pointing at the local helper. Skill body adjusted to invoke local-helper tools alongside remote-MCP tools
Kobiton server (api.kobiton.com/mcp) Unchanged

Tradeoffs. Smallest lift of any variant — Kobiton-side does no work; the plugin + Intent Solutions / community absorb the build. It also helps NON-Claude clients today (Cursor / Codex CLI / Gemini CLI users get the same workflow). The downside: the user still has to install two things, and the local MCP still requires the user to have Appium + a runtime installed locally. The variant doesn't reduce local-toolchain dependence; it just makes it portable across MCP clients.

Best paired with: variant 2 (staging-upload) for the upload portion; variant 1 handles script execution, variant 2 handles app delivery.

3.2 Variant 2 — Staging-upload pattern

How it works. User uploads the test script (or APK / IPA) to a Kobiton-owned pre-signed URL FIRST. Then a single high-level MCP tool — call it executeTestRun(scriptUrl, targetSpec) — takes the URL reference and does the entire orchestration server-side. No local filesystem needed after upload.

sequenceDiagram
    participant U as User
    participant C as Client (Claude)
    participant K as api.kobiton.com/mcp
    participant S as Kobiton S3

    U->>K: GET presigned PUT URL
    K-->>U: presigned URL

    U->>S: PUT test script
    S-->>U: 200 OK

    C->>K: executeTestRun(scriptUrl, targetSpec)

    activate K
    K->>K: createSession on selected device
    K->>S: fetch script
    K->>K: run Appium against session
    K->>K: collect artifacts
    deactivate K

    K-->>C: session record + artifact URLs
Loading

What changes.

Side Change
Client One-tool call instead of the current ~6-step orchestration. The 3-step upload (uploadAppToStore → PUT → confirmAppUpload) becomes a 1-step getUploadUrl → PUT. Skill body shrinks substantially
Plugin tools/sessions.yaml adds executeTestRun definition. Skill body simplifies to "ask user → upload script → call executeTestRun → present results." Probably halves the skill's length
Kobiton server New endpoint POST /api/v2/uploads/presign returns a pre-signed PUT URL. New high-level executeTestRun tool that orchestrates session creation + script fetch + run + artifact collection. Server-side Appium runner exists or is added

Tradeoffs. Universal lift — every MCP client (and every Claude surface that supports MCP, including mobile) gets a one-tool workflow. Eliminates the async-race problem from R2 finding #34 because the server controls all timing internally. The downside: requires Kobiton to operate a server-side Appium runner, which is a real ops commitment (queue management, sandboxing, observability, scaling). It also reduces the surface area for client-side innovation — once the server runs everything, the client is mostly a thin invoker.

Best paired with: variant 1 for the file-pickup step (instead of a pre-signed PUT, use the local helper); variant 4 if Kobiton wants the runner to be the long-term anchor.

3.3 Variant 3 — Bundled host (desktop app or polished Cowork bundle)

How it works. Kobiton ships its own host — either a standalone desktop app or a curated, branded Cowork plugin bundle — that owns the file-picker UX, bundles a local Appium runtime, and pairs with the existing remote MCP for device/session work.

flowchart TB
    subgraph host["Kobiton-branded host"]
        direction TB
        flavor["3a — Desktop app (Mac / Windows) OR<br/>3b — Cowork plugin bundle (via claude.com/plugins)"]
        components["Components:<br/>• native file picker<br/>• bundled Appium 2.x runtime<br/>• script editor (optional)<br/>• artifact viewer<br/>• device picker UI"]
        flavor -.- components
    end
    KM["api.kobiton.com/mcp<br/>(device + session work)"]
    host --> KM
Loading

Two flavors:

3a — Standalone desktop app. Kobiton-branded; Mac + Windows installer; could be Electron / Tauri / native. Owns the UX end-to-end. Pairs with the remote MCP via HTTP. No Claude dependency at all.

3b — Polished Cowork plugin bundle. Distributed via claude.com/plugins. Uses Cowork's existing host (sandboxed Ubuntu VM, file picker, plugin marketplace) but bundles Kobiton-specific UX through .claude-plugin/ skills + agents + hooks. Same architectural prerequisites as Cowork — per Cowork extensions docs — though drop-in plugin portability across Claude Code and Cowork is not yet formally documented by Anthropic and depends on the install test referenced in #53.

What changes.

Side 3a (desktop app) 3b (Cowork bundle)
Client Kobiton's app, not Claude Cowork (existing host)
Plugin (kobiton/automate) Mostly unchanged — remote MCP still primary Refined .claude-plugin/ package with Cowork-specific UX hints, scheduled tasks, agent definitions
Kobiton server Unchanged or minor (host emits some app-specific instrumentation) Unchanged
Kobiton brand Owns the surface entirely Branded inside Cowork; Cowork brand is co-primary

Tradeoffs. Strongest "AI native to Kobiton" perception (variant 3a especially — it's a Kobiton-branded product). Reduces customer confusion about "do I need to buy Claude separately?" because the app ships with everything. The downside: 3a is a meaningful product-engineering investment (desktop app maintenance, OS-specific installer pipelines, update channel). 3b is much cheaper — leverages existing Anthropic infrastructure — but inherits Cowork's audience (mostly Claude-Pro / Claude-Max subscribers) and brand co-presence.

3b also depends on the Cowork install test we committed to in #53 (one-afternoon empirical scope) to confirm cross-surface plugin portability before shipping.

Best paired with: variant 2 — a bundled host with a high-level executeTestRun tool is much simpler than a bundled host that has to orchestrate the multi-step flow itself.

3.4 Variant 4 — Kobiton-hosted test runner

How it works. The test runner lives entirely server-side. The user submits a script + a target spec via a single MCP tool, and Kobiton runs everything on cloud-side infrastructure. No local toolchain, no local FS dependency, no client-side Appium runtime.

flowchart LR
    CL["Client<br/>(any MCP-capable<br/>Claude surface)"]
    MCP["api.kobiton.com/mcp"]

    subgraph runner["Kobiton cloud test runner"]
        WP["sandboxed Appium 2.x<br/>worker pool"]
        QS["queue + scheduler"]
        DR["device reservation"]
        AP["artifact pipeline"]
        OT["observability<br/>(OTel spans)"]
    end

    RES["Returns:<br/>session record<br/>artifact URLs<br/>pass / fail"]

    CL -->|"executeTestRun<br/>(scriptContents or scriptUrl,<br/>targetSpec)"| MCP
    MCP --> WP
    WP --> QS
    QS --> DR
    DR --> AP
    AP --> OT
    OT --> RES
Loading

This is variant 2 taken to its logical conclusion — instead of relying on the client to deliver the script, the server runs it from end to end. The client doesn't need a local runtime at all; mobile, claude.ai web, claude.ai/code cloud sandbox all work equally well.

What changes.

Side Change
Client Same one-tool call as variant 2. No local Appium runtime. Works from claude.ai web, claude.ai/code cloud sandbox, mobile, Cowork, Desktop, any MCP client
Plugin (kobiton/automate) Significantly simplified — skill body becomes "ask user, send script to executeTestRun, present results." Probably ~1/4 the current length
Kobiton server Major build: sandboxed Appium worker pool, queue / scheduler, observability (OTel spans per session for cross-client portability — see jeremylongshore/automate#28), artifact pipeline, security model for arbitrary user-submitted scripts

Tradeoffs. Universal lift — every MCP client benefits equally, including ones that can't run local code at all (mobile, web). Eliminates the "Claude Pro/Max licensing" perception entirely because the workflow runs anywhere a user can configure a Custom Connector. The downside: this is the biggest Kobiton-side investment of any variant. It's also a security-sensitive surface (server runs arbitrary user-submitted Appium scripts on devices; needs sandboxing + abuse rate-limits + a clear policy on what scripts are allowed). The "AI-native" framing is fully realized here, but the path from today's plugin to a hosted runner is a meaningful product pivot.

Best paired with: none — variant 4 supersedes variants 1, 2, and 3 in capability. Worth doing if Kobiton wants the long-term anchor; variants 1 and 2 are faster steps toward the same destination.

4. Consolidated tradeoff matrix

Comparing all four across consistent dimensions:

Dimension V1: Hybrid V2: Staging-upload V3: Bundled host V4: Hosted runner
Relative Kobiton-side scope None — Kobiton's existing MCP unchanged New endpoint + new high-level tool New product surface (3a) or new bundle (3b) New cloud infrastructure (worker pool + queue + observability)
Cross-client lift Every MCP client w/ stdio support Every MCP client incl. mobile + web Cowork users (3b) or Kobiton-app users (3a) Universal — every MCP client incl. mobile + web
Local-toolchain dependence Still required Still required (until upload completes) Bundled within host Eliminated
"AI-native to Kobiton" perception Low (still external Claude-branded) Medium (one-tool feel) High (3a) / Medium (3b) Highest
Procurement / licensing concern Customer still buys Claude Customer still buys Claude Reduced (3a fully Kobiton-branded) Eliminated for the workflow itself
Security surface area Local exec (existing) Same as today + presigned URL Same as today + bundled runtime Server-side arbitrary-script exec — new attack surface
Compounds with which SEPs None directly SEP-2356 (file input) cleans this up later SEP-2640 (Skills as MCP primitive) tightens 3b SEP-2532 (resource streaming), SEP-1610 (declarative chaining) compound here
Reversibility Easy — remove local MCP Medium — deprecate executeTestRun is awkward Hard (3a) — desktop app investment / Medium (3b) Hardest — server-side runner is operational commitment

This matrix deliberately does not estimate time-to-deliver, headcount, or implementation effort for any variant — those depend on Kobiton's internal resourcing and prioritization and are not Intent Solutions' call to make. The "right" variant depends on Kobiton's read on three things: how much the "AI-native" customer perception matters (V3a / V4 score highest); how much server-side investment is appetite-compatible (V1 / V3b are the lightest, V4 the largest); and whether cross-MCP-client portability is a strategic priority (V2 / V4 lift every client equally, V3a / V3b favor specific surfaces).

5. What this is NOT

  • Not a roadmap. Each variant is independently shippable; the order and combinations are Kobiton's call. This sketch maps the levers, not the commit.
  • Not a SOW change. The Intent Solutions R-series engagement scope is unchanged. This sketch is a structural artifact responding to #53 ask 6 — decision-support, not deliverable.
  • Not a recommendation. The matrix in section 4 is deliberately neutral; "what's right" depends on Kobiton's commercial + strategic context, not on the architecture in isolation.
  • Not the bundled-host implementation. This is a tradeoff-analysis sketch. The actual builds — whether of variant 1's local helper or variant 2's staging-upload endpoint or variant 3's host or variant 4's runner — each warrant their own design doc with detail well beyond this sketch's scope.
  • Not a substitute for the one-pager or the README compatibility matrix. Those address different #53 asks (the one-pager maps each ask to a layer; the README distills surface compatibility for customers). The bundled-host sketch addresses ask 6 specifically.

6. References

Originating thread

Companion artifacts

  • Architectural one-pager — maps each #53 ask to MCP-protocol (L1) / client-implementation (L2) / tool-quality (L3) layer
  • README compatibility matrix PR — customer-facing 6-row distillation
  • Upstream finding slate (#55, #56, #57, #58, #59, #60) with reading-order anchor #61 — the six server-side findings from mimosa767's audit that affect all four variants' tool-quality column

MCP spec proposals referenced

Anthropic surface documentation (verified by direct fetch 2026-05-18)

  • Jeremy Longshore intentsolutions.io
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment