# Skill: Route AI agent tasks between local and cloud models using a privacy-and-complexity decision framework

> Apply this skill when designing or advising on an AI agent's architecture to decide which tasks run on local hardware and which call a cloud model, including building a hybrid setup.

Source: sodigi-learn -- local-agents/lokalnyy-vs-oblako -- https://sodigi.io/learn/local-agents/lokalnyy-vs-oblako

## When to use
- User is designing an agent and needs to decide which steps run locally vs in the cloud.
- User is overspending on cloud tokens for tasks a local model could handle.
- User has sensitive data flowing through an agent and needs to audit whether any of it reaches external servers.
- User is building a cost/privacy-optimized hybrid agent architecture.

## Core rules
- The two routing questions are: (1) Is the data sensitive? (2) Is the task hard? These two questions resolve the vast majority of cases.
- Sensitive data never leaves the machine, regardless of task complexity. This is a hard rule.
- Simple non-sensitive tasks default to local to avoid unnecessary cost.
- Hard non-sensitive tasks go to the cloud for the best result.
- Hard AND sensitive tasks require either a larger local model or stripping PII/identifiers before sending to the cloud.
- A hybrid agent (local by default, cloud on flagged hard tasks) almost always outperforms a pure-local or pure-cloud agent.
- "Local is free" is incomplete: hardware and electricity are real costs, just smaller and more predictable than tokens.
- Never fill the local model's memory to the brim: leave headroom for the OS and context, or both the machine and the agent will freeze.

## Procedure
1. List every distinct task the agent must perform.
2. For each task, answer the two routing questions:
   - Can this data leave the machine? (No = local, stop.)
   - Is this task hard? (Routine = local; complex reasoning/creative = cloud candidate.)
3. Mark tasks that are both sensitive and hard: plan to either use a larger local model or anonymize before cloud dispatch.
4. Configure the agent to run locally by default and escalate to the cloud only for tasks flagged as hard and non-sensitive.
5. If cost is a concern, estimate the per-task cloud token spend for one week and compare to the value of the result quality.
6. Review after one week: move tasks back to local if the cloud bill is too high; move tasks to cloud if local quality is insufficient.

## Ready-to-use prompt
```
Help me design the local-vs-cloud routing for my AI agent.

Agent overview:
- What the agent does: [describe the pipeline / tasks]
- Data it handles: [type of data, sensitivity level]
- Current setup: [local model running / cloud API / neither yet]
- Budget tolerance: [willing to pay for cloud / want to minimize cloud use]

For each task in the agent, please:
1. State whether the data can leave the machine (yes / no / depends).
2. Rate task complexity: routine (sorting, rewriting, short Q&A) or hard (long reasoning, creative, code debugging).
3. Assign each task: local / cloud / local-first-with-cloud-fallback.
4. Flag any task that is both sensitive AND hard and propose a mitigation.
5. Summarize the hybrid architecture: what runs locally, what hits the cloud, and what the trigger condition is.
```

## Pitfalls
- Sending everything to the cloud by default: you overpay and leak data that had no business leaving the machine.
- Treating "local" as zero cost: electricity and hardware depreciation are real, just more predictable than a token bill.
- Expecting a small local model to perform like a top cloud model: assign it appropriate tasks, not the hardest ones.
- Saturating local memory by giving the model the machine's entire RAM: always leave buffer for the OS or the agent will freeze.
- Sending sensitive data "just this once" to the cloud for a quick result: once transmitted, you cannot take it back.
- Defaulting to pure-local or pure-cloud instead of evaluating a hybrid: a hybrid almost always delivers better cost/quality/privacy balance.