{"id":25,"date":"2026-07-18T15:47:09","date_gmt":"2026-07-18T15:47:09","guid":{"rendered":"https:\/\/resources.stage.magicassist.co\/blog\/local-cloud-runtimes\/"},"modified":"2026-07-18T15:47:09","modified_gmt":"2026-07-18T15:47:09","slug":"local-cloud-runtimes","status":"publish","type":"post","link":"https:\/\/magicassist.co\/blog\/local-cloud-runtimes\/","title":{"rendered":"Where your AI agent work happens"},"content":{"rendered":"

Your agent works where its tools and files live<\/h2>\n

MagicAssist is the shared control room, not the machine that does every task. The actual work happens in a connected environment that has the right files, tools, and approved access. That environment might be a laptop, a dedicated computer, or a private server. You do not need to master the infrastructure to make a good choice. Start with what the task needs and what it should never reach.<\/p>\n

This split is a core product decision. It lets the team coordinate work in one workspace without requiring every repository, API key, or local tool to live in that workspace. The runtime remains the place where execution access is configured. MagicAssist provides visibility and dispatch around it.<\/p>\n

Understanding the split also improves troubleshooting. A queued issue may be perfectly written while its runtime is offline. A running task may fail because a local command is missing. A server can be healthy while a daemon has lost authentication. \u201cThe agent is not working\u201d is not one problem; it can occur at several layers.<\/p>\n

Server, daemon, and coding tool<\/h2>\n

Each component has a narrow job. The server owns shared coordination. The daemon owns the connection to an execution environment. The coding tool performs the task. Keeping those jobs separate avoids treating the web interface as though it were a remote shell.<\/p>\n

Layer<\/th>Responsibilities<\/th>Typical failure signal<\/th><\/tr><\/thead>
Server<\/td>Issues, comments, assignments, task queue, workspace state, and real-time updates<\/td>The workspace or API is unavailable, or dispatch state cannot be recorded<\/td><\/tr>
Daemon<\/td>Tool detection, runtime registration, polling, heartbeat, process launch, and result reporting<\/td>Runtime appears offline or tasks remain queued<\/td><\/tr>
AI coding tool<\/td>Repository inspection, tool use, file changes, tests, and task response<\/td>The execution fails, reports a blocker, or cannot use a required command<\/td><\/tr><\/tbody><\/table><\/figure>\n

The daemon is part of the MagicAssist CLI and can run as a background service. On startup it authenticates, detects supported coding tools in its environment, registers the corresponding runtime records, and begins polling for work while sending regular heartbeats. The desktop application can manage a daemon for users who prefer that route.<\/p>\n

The coding tool remains itself. Claude Code, Codex, and other supported tools have different capabilities, configuration conventions, and ways of discovering Skills or connected tooling. MagicAssist routes work to the configured tool; it does not make every provider behave identically.<\/p>\n

\"MagicAssist
Use this architecture to decide which environment, tools, and access each job requires.<\/figcaption><\/figure>\n

A runtime is a concrete capability boundary<\/h2>\n

A runtime represents a daemon and one detected coding tool within a workspace. One machine can therefore expose several runtimes if it has several supported tools installed. The distinction matters because each runtime can have different model access, Skills behavior, external commands, concurrency, and repository availability.<\/p>\n

  • The machine defines which files, repositories, and local services exist.<\/li>
  • The installed coding tool defines how the agent executes and which native capabilities it understands.<\/li>
  • The daemon reports health and claims eligible tasks.<\/li>
  • The agent configuration defines role, provider choice, concurrency, and attached Skills.<\/li>
  • The issue defines the current objective and authorized scope.<\/li><\/ul>\n

    This makes runtime selection part of task design. A task that needs a checked-out monorepo should run where that working copy exists. A browser research task should use an environment with the approved browser capability. A deployment review may use a restricted runtime that can inspect configuration but cannot deploy. Do not broaden one runtime’s access simply because an agent might someday need it.<\/p>\n

    Choose environments by the work they must support<\/h2>\n

    Teams commonly connect personal development machines, dedicated local machines, VPS environments, or other privately managed compute. MagicAssist also offers managed deployment options in which the application, database, and a dedicated runtime can be configured together. The right environment is not a universal \u201clocal versus cloud\u201d preference. It follows from dependencies, continuity, isolation, maintenance, and review.<\/p>\n

    A developer laptop fits work that depends on an active local checkout, desktop-only tools, or hands-on inspection. Its weakness is continuity: it sleeps, travels, changes network, and competes with interactive work. A dedicated machine or VPS fits standing tasks that should remain available independently of one person’s laptop. Its weakness is maintenance: repositories, credentials, tool versions, storage, and updates need an owner.<\/p>\n

    A hybrid setup is often sensible. Interactive feature work can stay close to the developer’s active checkout. Recurring reports or repository maintenance can run on a dedicated environment prepared for that purpose. MagicAssist provides one coordination surface across those runtimes, but the team must still design how code and artifacts move between them.<\/p>\n

    Inventory access before assigning the agent<\/h2>\n

    Runtime problems often look like reasoning problems. The agent says it cannot find a repository, a test command fails because the required service is absent, or a connected tool is available on one machine but not another. Prevent this by inventorying dependencies as part of the issue or role design.<\/p>\n

    1. Which repository or working directory is required?<\/li>
    2. Which branch or worktree should the task use?<\/li>
    3. Which command-line tools and versions are required?<\/li>
    4. Which network destinations or connected services are authorized?<\/li>
    5. Which credentials exist in the runtime, and which must remain unavailable?<\/li>
    6. Where should the resulting artifact be written?<\/li>
    7. How will a reviewer reach the output without relying on the runtime session?<\/li><\/ol>\n

      The inventory should distinguish availability from permission. A production credential may exist on a VPS, but an issue that asks only for a plan does not authorize its use. A browser may be available, but access to a private dashboard still needs an explicit task boundary. MagicAssist can advertise capabilities and route work; the issue and operating policy define whether using them is appropriate.<\/p>\n

      Online, missing, and saturated are different states<\/h2>\n

      The daemon sends regular heartbeats so MagicAssist can show whether a runtime is online. If heartbeats stop, the runtime is marked missing and in-flight work can fail with a runtime-related reason. When the daemon returns, the runtime can become available again. This protects the queue from pretending a disconnected machine is still executing.<\/p>\n

      An online runtime can still be busy. Concurrency limits exist at both the daemon and agent levels. When the permitted slots are full, new work waits in the queue. Raising limits is not automatically better; parallel tasks compete for CPU, memory, repository locks, rate limits, and reviewer attention. Choose a limit the environment and workflow can support.<\/p>\n

      A healthy runtime can also be incompatible with the task. The assigned agent may use a different coding tool, a required capability may be absent, or the environment may not contain the project. Runtime visibility helps narrow the diagnosis, but the team should inspect the task’s dependencies rather than treating \u201conline\u201d as proof of readiness.<\/p>\n

      Design recovery before relying on long-running work<\/h2>\n

      If a daemon exits while tasks are dispatched or running, MagicAssist can mark those tasks failed and reclaim retryable work. This is useful infrastructure behavior, not a guarantee that replay is harmless. A task that sends a message, changes an external system, or runs a deployment may produce side effects before the daemon disappears.<\/p>\n

      Make repeatable tasks idempotent where possible. Record which object or commit a run acted on. Check current state before applying a change. Separate preparation from irreversible actions. Ask the agent to report partial completion and open questions. For high-impact work, require human approval before the final external action.<\/p>\n

      Autopilot runs need particular care because their failures are not automatically retried in the same way as common assignment or mention paths. The next schedule may create another run, which can overlap with partial side effects from the first. The Autopilot contract should define how to detect existing work and how reviewers identify a missing or failed run.<\/p>\n

      Keep secrets and source code in the right boundary<\/h2>\n

      The distributed model lets the coding tool use repositories and credentials in the connected environment rather than uploading them into the coordination workspace. That is a useful boundary, but it remains only as strong as the runtime configuration. The daemon and coding tool run with the permissions available to their process.<\/p>\n

      • Give a runtime only the repositories and services required for its role.<\/li>
      • Use separate credentials for automation where the external service supports it.<\/li>
      • Do not put secrets in issue descriptions, comments, Memory, or Knowledge Base documents.<\/li>
      • Review imported Skills and scripts before they reach a privileged runtime.<\/li>
      • Keep deployment authority separate from preparation when human approval is required.<\/li>
      • Rotate credentials when a runtime changes owner or purpose.<\/li><\/ul>\n

        A managed deployment can reduce setup work, but it does not remove the need to decide which repositories, credentials, and external tools belong on the dedicated machine. Infrastructure ownership may be delegated; access design cannot be.<\/p>\n

        A practical runtime decision<\/h2>\n

        For each recurring agent role, write a one-page runtime profile. Name the machine or environment, coding tool, repositories, expected commands, connected services, concurrency limit, maintenance owner, and review path. Link that profile from the agent’s maintained context or operating handbook. Do not paste sensitive values into it.<\/p>\n

        Choose a runtime because it has the right dependencies and boundaries for the work, not because \u201clocal\u201d or \u201ccloud\u201d sounds inherently better.<\/p><\/blockquote>\n

        Start one agent on one environment and run a bounded issue. Confirm that the daemon stays online, the coding tool is detected, the repository is correct, progress returns to the issue, and the reviewer can inspect the output. Then test recovery: stop the daemon during a safe task, restart it, and observe the task state. Operational confidence comes from seeing the whole path work, not from the runtime appearing in a list.<\/p>\n

        Once the path is understood, add environments for distinct reasons: continuity, isolation, provider choice, data location, or workload. MagicAssist gives those environments a common queue and visible history. The team gives each one a deliberate purpose.<\/p>","protected":false},"excerpt":{"rendered":"

        MagicAssist keeps planning in one place while work happens in a connected environment. Choose where each AI agent runs by considering its files, tools, access, continuity, and review needs.<\/p>\n","protected":false},"author":0,"featured_media":164,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-25","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guides"],"_links":{"self":[{"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/posts\/25","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/comments?post=25"}],"version-history":[{"count":11,"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/posts\/25\/revisions"}],"predecessor-version":[{"id":340,"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/posts\/25\/revisions\/340"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/media\/164"}],"wp:attachment":[{"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/media?parent=25"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/categories?post=25"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/magicassist.co\/blog\/wp-json\/wp\/v2\/tags?post=25"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}