\n\nExternal product documentation reviewed on October 12, 2026. Historical cases and local operating choices are preserved.
\n
A guided model is an agent that is allowed to reason and propose broadly, but whose ability to act is trimmed by an environment designed to require human intervention at the sensitive points.
\nSafety should not depend on the model “remembering” to ask. An instruction like ask me before installing anything improves the expected behavior, but it is not a barrier. If the harness lets it run any command, the process has access to credentials and the network reaches production, the action is still technically possible.
\nDisaster prevention comes from how well the place where the agent works is built:
\nThe master rule is simple: instructions steer; the environment limits.
\nThey define intent and method:
\nThey are essential for producing good work, but they are a soft policy. The model can misread a sentence, forget a restriction after a long conversation or believe an action is an obvious consequence of the goal.
\nThe CLI or environment that translates the model’s decisions into real actions: Codex, Claude Code, OpenCode or another agent.
\nThe harness can:
\nThis is the first enforcement layer. If ssh, git push or an edit are set to deny, the model should not be able to turn its intent into that action through the normal tool.
It includes the operating system, container, sandbox, user, worktree and connectivity.
\nAn agent can have permission to run a shell and still be contained if:
\nThis layer protects you even when the harness is misconfigured or an unforeseen path appears.
\nThe credentials and permissions of the target system:
\nIt is the last net. Even if the agent escapes the previous layers, it should not hold authority to perform an action it never needed.
\nIn an OpenCode session with GLM 5.3, the agent could install a library or connect over SSH without asking. It only stopped if the instruction explicitly told it to request permission first.
\nThe behavior is not explained solely by the model’s personality. In OpenCode V1, most permissions start at allow; the Build agent has broad access, and both installing dependencies and running ssh go through bash. If bash is enabled, there is no mandatory pause between the decision and the execution.
The instruction “ask me first” added a convention. The environment still allowed acting without it.
\nFor that V1 configuration, the durable solution is not writing a more dramatic threat into the prompt. It is configuring bash so sensitive actions are ask or deny, and removing from the environment the credentials the agent does not need.
Using a model outside OpenAI or Anthropic does not mean being left without controls. If GLM, DeepSeek, Qwen or any other model runs inside OpenCode, tool calls still go through OpenCode and can be subject to its permissions.
\nWhat changes is the degree of integration and predictability:
\nThat is why the model must not be the boundary. The policy has to survive a change of provider.
\nCodex separates two dimensions that are often mixed up:
\nThe three classic sandbox levels are:
\nread-only;workspace-write;danger-full-access.But that is not the same as three complete operating modes. Approval is configured separately through policies such as on-request, never or granular per-category controls. There are also built-in permission profiles such as :read-only, :workspace and :danger-full-access.
The value of this separation is that you can allow editing inside the workspace and, at the same time, require approval for an escalation or flatly reject certain kinds of request. The current reference adds approvals_reviewer = "user" | "auto_review": it changes who reviews eligible requests, not the sandbox or actions already allowed inside it. Codex configuration.
Claude Code offers interaction modes such as:
\ndefault, shown as Manual;acceptEdits;plan;bypassPermissions when enabled;auto when available in the session;dontAsk, which rejects calls that would need to prompt.In auto, a classifier reviews eligible actions; that is not human approval at every step. bypassPermissions retains documented exceptions and does not remove every control. Current permissions.
On top of those modes, rules let you classify tools or commands as allow, ask or deny. bypassPermissions should not be confused with “working faster”: it removes pauses and only makes sense inside a container or VM where the scope is already controlled from outside.
OpenCode uses allow, ask and deny permissions, configurable globally and per agent. It can apply rules to editing, shell, access to external directories, web, skills and subagents, even distinguishing commands through patterns.
In V1, Plan restricts edits and bash; --auto approves requests that would be ask, while respecting deny. V2 changes the schema to a permissions array with action, resource and effect, and renames bash to shell and task to subagent. Its Plan agent blocks edits except planning files, but that is not a blanket shell restriction. V2 permissions.
The conclusion is not that OpenCode lacks control. It is that you have to design it: its defaults prioritize fluency and do not automatically represent a conservative policy.
\nThe October 12, 2026 operational review adds a practical distinction. A role profile can say “read-only” without demonstrating that the session loads its rules or that every tool respects the boundary. In the reviewed OMP installation, effective enforcement remained unverified and LSP operations needed specific attention. That is a control awaiting validation, not a guaranteed sandbox.
\nIn the same case's n8n integration, a copy-generating proxy was replaced with a positive tool catalog, a bounded-write filter and readback: reading the resulting state to compare it with the permitted change. The reviewed records show positive and negative tests for that circuit; they do not demonstrate every failure mode. Hook failure, invalid output and timeout were not measured, so readback and recovery remained necessary.
\nThe lesson is not that a filter makes any tool safe. Authorization must describe the object and operation, verification must observe the effect, and untested boundaries must stay visible. Small LIVE autonomy in the V4 case depends on that explicit scope; it does not extend the same authority to any agent or project.
\nRather than memorizing mode names that change between tools, it is better to define stable capabilities.
\nUse: discovery, audit, planning and review.
\nUse: everyday development with human intervention on surface-level changes.
\nUse: well-specified tasks that are easy to validate.
\nUse: long jobs where manual pauses cost more than recreating the environment.
\nThis example preserves V1 syntax: do not copy it as V2 configuration. V2 requires migrating the rules and testing their effects; renaming a key does not turn the object into the required array. This profile allows local exploration, asks before editing or installing and blocks access that should not happen from a regular worker:
\n{\n \"$schema\": \"https://opencode.ai/config.json\",\n \"permission\": {\n \"*\": \"ask\",\n \"read\": \"allow\",\n \"glob\": \"allow\",\n \"grep\": \"allow\",\n \"list\": \"allow\",\n \"lsp\": \"allow\",\n \"edit\": \"ask\",\n \"external_directory\": \"deny\",\n \"bash\": {\n \"*\": \"ask\",\n \"git status*\": \"allow\",\n \"git diff*\": \"allow\",\n \"git log*\": \"allow\",\n \"rg *\": \"allow\",\n \"npm install*\": \"ask\",\n \"pnpm add*\": \"ask\",\n \"ssh *\": \"ask\",\n \"scp *\": \"ask\",\n \"rsync *\": \"ask\",\n \"docker *\": \"ask\",\n \"git push*\": \"deny\",\n \"sudo *\": \"deny\",\n \"rm -rf *\": \"deny\",\n \"*deploy*\": \"deny\"\n }\n }\n}OpenCode evaluates rules by match and the last matching rule wins, which is why the catch-all comes first and the exceptions after.
\nThis example is an editorial baseline, not a universal configuration. Each project must declare its safe commands and forbidden operations. A pattern as broad as *deploy* can also block innocent commands containing that text; the real policy has to be tested with the CLI and version in use.
The negative test is key. Seeing git status work does not prove ssh production is blocked.
Enforcement prevents unauthorized actions, but a good instruction reduces pointless attempts and improves reasoning:
\nYou are working in a guided environment.\n\nYou may inspect the repository and run read-only local validations.\nBefore editing, installing dependencies, using a private network or opening an SSH connection,\nexplain why it is needed and request approval.\n\nDo not push, deploy, run migrations or make external changes.\nIf a necessary action is blocked, do not look for an alternative route:\nstop and hand over the proposed command or change for human review.The most important sentence is do not look for an alternative route. A goal-oriented agent can read a block as a technical obstacle it should solve. The instruction makes clear that, in this context, the block is a governance decision.
\nA good environment does not try to guess whether the model will be obedient. It assumes any model can make mistakes, forget context or chase the goal with too much enthusiasm.
\nThe quality of the model determines how much useful work it produces inside the perimeter. The quality of the environment determines how much damage it can do outside it.
\n\n\nExternal product documentation reviewed on October 12, 2026. Historical cases and local operating choices are preserved.
\n
Working from Codex, Claude Code or OpenCode in a terminal does not make the model more capable than the one chatting on the web. It changes its position relative to the work.
\nIn a chat without a connected execution environment, the model receives a question, files the person chose or a copy of the context. In a CLI, the agent can inhabit the repository: read its current state, inspect history, modify files, run commands and observe the result.
\nThe useful difference is handed-over context versus verifiable context, and recommendation versus execution loop. That boundary does not necessarily match browser versus terminal: Claude Code can also work on repositories from the web. Choose by environment access, tools and permissions, not just the appearance of the interface. Official surfaces.
\n\n\nThe decisive difference is whether the agent can inspect, act and verify in the actual execution environment.
\n
The CLI can go through a complete sequence without a person copying each result:
\nThat feedback shrinks the gap between what the model believes and what the system does. A convincing answer can be wrong; a test run against the project provides evidence.
\nFrom the terminal, the agent can access —if the environment allows it—:
\nAGENTS.md or CLAUDE.md;There is no need to manually compress all of that into a prompt. The agent can discover it and cite its evidence.
\nA CLI plugs into pipes, scripts, CI, scheduled tasks and non-interactive processes. It also lets you repeat the same method across sessions: prepare a worktree, run an audit, validate a result and produce an artifact.
\nThat makes it especially valuable for a coordinator–workers setup: one terminal keeps the global view and others solve bounded tasks in isolated spaces.
\nWeb interfaces like ChatGPT or Claude are an especially comfortable surface for:
\nThe line is not absolute either. Modern web experiences can connect repositories and run remote agents; CLIs can converse, research and produce documentation. The right question is where the authoritative context lives and where it makes sense to close the loop.
\n| Work | \nSuggested surface | \nWhy | \n
|---|---|---|
| Explore an idea or compare approaches | \nWeb | \nBroad conversation and a mix of sources | \n
| Understand a repo’s exact behavior | \nCLI | \nAccess to real state and tools | \n
| Implement a multi-file change | \nCLI in a worktree | \nEditing, tests and a traceable diff | \n
| Produce a portable report or guide | \nWeb, with evidence from the CLI | \nBetter synthesis without losing verification | \n
| Prototype a visual direction | \nWeb or canvas | \nMore direct visual iteration | \n
| Integrate the prototype into the product | \nCLI | \nFitting it against components, build and tests | \n
| Automate a repeatable task | \nCLI or SDK | \nComposable, non-interactive execution | \n
| Operate on production | \nHuman gate and restricted environment | \nThe surface does not replace control | \n
The terminal also increases the blast radius. If the process can see SSH keys, cloud tokens, a production database and an unrestricted shell, the agent can act on all of it.
\nThat is why CLI does not mean safe. It means close to the system. That closeness is an advantage only when it comes with:
\nallow, ask and deny permissions;The editorial on guided models develops this idea: instructions steer, but the environment limits.
\nUse the conversation to clarify the goal, audience, constraints, risks and success criteria.
\nOpen the project, check the real state and turn the intent into a plan grounded in concrete files, commands and dependencies.
\nDelegate implementations, audits or tests to separate worktrees. Each worker gets a verifiable task and the minimum authority it needs.
\nThe coordinator reviews diffs, runs the relevant suite and resolves interactions between changes.
\nTurn the result into a guide, decision or artifact that another person —or their agent— can reuse without inheriting all the operational noise.
\nMove from the web to the terminal when the answer depends on the live state of a system and needs a loop of inspection, action and verification. Go back to the web when the main value lies in understanding, deciding or communicating.
\nThere is no superior surface. There is a surface that is more honest about the task.
\n\n\nReviewed on October 12, 2026. Names, limits and catalogs change; check the official model pages before turning this guide into policy.
\n
Choosing a model means assigning capability to a task. Before looking at the selector, answer:
\nA worker with a bounded goal, clear tests and little context does not need the biggest model. A coordinator that has to keep the intent, spot conflicts between five changes and decide what to merge can justify it.
\nThe economic rule is cost per solved task, not cost per token. A cheap model that gets into loops, fails tests or needs three retries can end up more expensive than a better one used once.
\nBefore switching families or moving up to the premium model:
\nRaising reasoning helps when the model can solve the problem but needs to explore more. Moving up a model helps when there is a capability gap: it misses relationships, cannot hold the horizon, misjudges tradeoffs or repeats the same kind of mistake.
\n| Model | \nSuggested role | \nRecommended tasks | \nWhen to move up | \n
|---|---|---|---|
| GPT-6 Luna | \nFast, efficient worker | \nExtraction, summaries, tests, documentation and verifiable local changes | \nThe task needs sustained judgment across files | \n
| GPT-6.1 Sol | \nStrong generalist or coordinator, when available | \nComplex code, research, tool use and agentic workflows with several constraints | \nEven with high reasoning it cannot carry the work end to end | \n
| GPT-6 Astra | \nCoordinator and judge for the hardest demands | \nArchitecture, extensive synthesis, ambiguous decisions, deep research and long workflows | \nReserve it for the hard tail, not as the default | \n
Luna is ideal when the task contract fits in a few sentences and the result has a clear check. Sol is the next step for work that needs interpretation, autonomy and coordination.
\nMove to Sol when several of these signals show up:
\nAstra is justified when the problem combines breadth, ambiguity and consequences: it must not only write well, but preserve coherence over a long process and judge the whole.
\nGPT-6.1 Sol is OpenAI’s current recommendation for complex coding where the account and client support it. GPT-6 Sol and GPT-5.6 remain alternatives during rollout. Availability depends on plan, client and workspace; changing a configuration name does not grant access. Models and availability.
\nHaiku 5.5 was released on October 7 and Sonnet 5.5 on September 28, 2026. These are Anthropic catalog versions; each provider and harness must expose them separately. Haiku · Sonnet.
\n| Model | \nSuggested role | \nRecommended tasks | \nWhen to move up | \n
|---|---|---|---|
| Claude Haiku 5.5 | \nFast worker | \nClassification, extraction, repetitive changes, bounded subagents and high-volume tasks | \nConsistency is lacking or the work needs reasoning across several pieces | \n
| Claude Sonnet 5.5 | \nBalanced default | \nEveryday development, analysis, content, tool use and medium-scope agents | \nThe horizon gets longer or the cost of wrong judgment rises | \n
| Claude Opus 5.5 | \nSenior coordinator | \nComplex agentic coding, broad planning, critical review and high-impact decisions | \nOpus at high effort still does not close the problem | \n
| Claude Fable 5.1 | \nFrontier for the hard tail | \nVery demanding reasoning and long-horizon agentic work | \nUse selectively and measure whether it improves the resolution rate | \n
Haiku works best as an executor of small, checkable units. Sonnet is a practical starting point when the task needs to understand intent as well as follow instructions. Anthropic currently recommends starting with Opus 5.5 for most workloads; this guide instead prioritizes cost per accepted task in a worker orchestration.
\nMove from Sonnet to Opus when:
\nAnthropic’s documentation recommends trying more effort first when the model has that option. If Opus at its highest levels is not enough, Fable is currently the next step for frontier problems.
The reasoning level is a deliberation budget, not a magic intelligence multiplier. In general, more reasoning means more time and more tokens, and lets the model explore hypotheses, revisit decisions and hold intermediate steps.
\n| Conceptual level | \nUse it for | \nAvoid it when | \n
|---|---|---|
| Low or light | \nLocal edits, direct questions and tasks with an obvious path | \nThere is ambiguity or several constraints in tension | \n
| Medium | \nDaily development, moderate debugging and reversible decisions | \nThe task is trivial or extremely complex | \n
| High or extra high | \nArchitecture, elusive bugs, migrations and multi-file synthesis | \nThe result is verified with a simple transformation | \n
| Max | \nA single model needs to exhaust a hard investigation | \nThe task could be split better across agents | \n
| Ultra | \nThe work splits naturally and it pays to delegate to subagents | \nThere is a single indivisible piece or lots of accidental coordination | \n
In Codex, Max gives the same model more time; Ultra can delegate to subagents. GPT-6 Luna supports up to Max, without Ultra. In Claude, behavior depends on the model: adaptive thinking and effort are soft controls. Haiku 5.5 supports adaptive thinking and effort, unlike Haiku 4.5. Haiku 5.5 specifications.
Two warnings:
\nprovider/model#variant selects options such as effort or token budget; names and effects depend on model and provider. Variants.OpenCode Go brings models from several providers together through Go and Go Plus. The following table is an editorial starting heuristic, not an official OpenCode benchmark. It groups relevant options from the catalog checked on October 12, 2026. Check the actual list in /models and the official page before assigning a worker.
| Go catalog options | \nSuggested starting point | \nInitial role | \n
|---|---|---|
| Grok 4.7 and 4.6 | \nIndependent review, broad reasoning and second opinion | \nSelective coordinator or reviewer | \n
| GLM 5.3 Flash, 5.3, 5.2 | \n5.3 Flash for bounded work; 5.3 for planning and cross-cutting changes | \nCheap worker; 5.3 as escalation | \n
| GPT-6 Luna and GPT-5.6 Luna | \nGPT-6 Luna for implementation, refactors, tests and verifiable docs; 5.6 as a tested fallback | \nGeneral worker | \n
| Kimi K3, K2.7 Code, K2.6 | \nK2.7 Code for code; K3 for synthesis and more demanding tasks | \nCode worker; K3 selectively | \n
| LongCat 2.0 | \nSimple maintenance, batches and repeatable tasks | \nVolume worker | \n
| MiMo V2.6 Flash and Pro; V2.5 and Pro | \nV2.6 Flash for cheap, checkable tasks; Pro when more judgment is needed; V2.5 as fallback | \nCheap worker | \n
| MiniMax M3 and M2.7 | \nM3 as a generalist; M2.7 as an evaluated fallback | \nGeneral worker | \n
| Muse Spark 1.3 and 1.2 Contributor (limited regions) | \nImplementation, tests and docs with a well-defined scope | \nBounded contributor | \n
| Qwen3.8 Max, 3.8 Flash, 3.7 Plus | \n3.8 Flash for volume; 3.8 Max for planning and review | \nWorker or reviewer depending on the variant | \n
| DeepSeek V4.1 Flash, V4 Pro, V4 Flash, V4 Flash Vision Exp | \nV4.1 Flash for routine work; Pro for debugging/review; Vision for visual inputs | \nSpecialized worker | \n
| Hy4 preview and Hy3 | \nHy4 only in an evaluation sandbox; Hy3 after a test against the repo | \nExperimental or evaluated worker | \n
| LongCat 2.5 Preview Free and Step 5 Preview Free | \nReproducible tests without relying on future availability | \nTemporary experimentation | \n
| Claude Haiku 5.5 | \nExtraction, classification and bounded subagents | \nVolume worker | \n
| Space Bunny | \nEvaluate small changes with tests | \nExperimental worker | \n
Five-hour, weekly and monthly allowances are expressed as dollar amounts per model: request counts are estimates, not guarantees. An inexpensive option can have a smaller allowance; free variants are temporary. Catalog and limits.
\nFor each family that looks promising, build a small set of real tasks:
\nMeasure resolution rate, retries, time, cost and respect for the contract. The final choice can differ per repository: a model that is excellent at coding can be a mediocre coordinator, and a very convincing one can ignore operational limits if the environment does not enforce them.
\nOlder catalog versions are useful as a fallback when an integration or behavior has been validated, but they should not be kept out of inertia. preview or Exp variants should stay off the critical path until they pass your own evaluation.
| Responsibility | \nMinimum useful capability | \nEscalation | \n
|---|---|---|
| Read-only discovery | \nFast model with low reasoning | \nMove up if it misses important relationships | \n
| Isolated change with tests | \nCheap worker with low or medium reasoning | \nImprove the contract; then move up the model | \n
| Multi-file bug | \nGeneralist with medium or high reasoning | \nEscalate if it repeats failed hypotheses | \n
| Coordinating several workers | \nStrong model with high reasoning | \nFrontier model if it cannot integrate the big picture | \n
| Security or architecture audit | \nStrong model plus a second opinion from another family | \nEscalate on disagreement or incomplete evidence | \n
| Irreversible action | \nNo model decides alone | \nHuman gate and external enforcement | \n
The selector is not a hierarchy of employees. It is a gearbox: the best gear is the one that delivers enough control and power without spending complexity where it adds no value.
\nA backend can compile and still fail to start. The build verifies that its steps finished; it does not prove that the production process resolves its imports, loads its configuration, opens the port and answers a request.
\nIn a real incident, an entry file ended up with duplicated content. The deploy went ahead, but the server entered a crash loop because of repeated declarations. Recovery required fixing the code and publishing again. The problem that mattered was already in the repository: what was missing was a test able to see it before the deploy.
\nIf a generator, a merge or an agent modifies the startup point, review the diff and run the runtime’s syntax check. Catch obvious duplications of imports, server initialization or whole blocks before calling the change done.
\nThis review is project-specific: it is not enough to search for a repeated string and assume every repetition is an error.
\nRun the production command in a test environment with the configuration it needs. Wait for the process to open the port and make an HTTP request to a lightweight endpoint. If the process dies or the request fails, the deploy is blocked.
\nDo not replace this check with development mode. Scripts, variables, bundlers and import paths can differ.
\nA minimal sequence, adapted to the project, looks like this:
\nnpm run build\nPORT=5000 npm run start\n# In another terminal:\ncurl --fail --show-error http://127.0.0.1:5000/healthThe example assumes start and /health exist; use the service’s real names. The process must be able to shut down cleanly when the test ends.
Configure the hosting healthcheck so a deploy is only considered ready when the backend responds. A static page or a process that started for an instant does not prove the API is operational.
\nThe health endpoint should be cheap and represent the capability you need to serve traffic. If it depends on external services, distinguish between process alive and service ready to avoid restarts caused by a temporarily unavailable dependency.
\nEach step answers a different question. A green check does not replace the next one.
\nThe task contract has to ask for concrete evidence: the command run, relevant output, the HTTP response code and the deploy result. The phrase “it works” is not enough to cross the production boundary.
\nIf the preflight fails, the agent fixes and repeats the test. If configuration is missing that only exists in production, it records what it could verify and what is left pending for an equivalent environment; it does not turn an assumption into approval.
\nOperational case records reviewed on October 12, 2026 add another version of the same problem. An n8n integration had passed 56 tests, an audit and static review, but had not executed its actual HTTP node. The first real request to the already published workflow failed in its HTTP node. This was a result in that circuit and configuration, not a universal n8n defect or proof that tests were useless: the path producing the effect was missing from coverage.
\nLater acceptance records documented two runs: change an authorized parameter, publish, read back the state and check the webhook response; then restore, publish again and verify that the webhook recovered its original behavior. Restoring a definition without checking the active version did not close the loop.
\nThis evidence was read in project records, not reproduced for this editorial. It also did not cover control-hook failures or timeouts. The current distinction is useful for any handoff: locally ready is not applied; applied is not accepted. An immediate postflight proves a specific condition; when the objective depends on routine use, observe the agreed natural operating cycle before closing. See the cockpit's evolution.
\nPublishing starts before the deploy button. First you have to prove that the same program that will receive traffic can start and respond. Then the hosting has to refuse to declare a deploy successful if it does not pass that test.
\n\n\n", "headings": [ { "label": "The false positive of a green build", "depth": 2, "id": "the-false-positive-of-a-green-build" }, { "label": "Three checks, three different questions", "depth": 2, "id": "three-checks-three-different-questions" }, { "label": "1. Does the entry file keep a valid structure?", "depth": 3, "id": "1-does-the-entry-file-keep-a-valid-structure" }, { "label": "2. Does the command production uses actually start?", "depth": 3, "id": "2-does-the-command-production-uses-actually-start" }, { "label": "3. Does the deploy wait for a healthy response?", "depth": 3, "id": "3-does-the-deploy-wait-for-a-healthy-response" }, { "label": "Order matters", "depth": 2, "id": "order-matters" }, { "label": "When an agent is doing the work", "depth": 2, "id": "when-an-agent-is-doing-the-work" }, { "label": "From local tests to published effects", "depth": 2, "id": "from-local-tests-to-published-effects" }, { "label": "Transferable rule", "depth": 2, "id": "transferable-rule" } ], "raw": "---\nslug: preflight-despliegue-backend\ntitle: Before publishing, test the real startup\ntype: guide\norder: 12\nsummary: \"A successful build does not guarantee the backend can start. A preflight with the production command and a blocking healthcheck close that gap.\"\ntags: [deploy, backend, preflight, healthcheck, production, agents]\nrelated: [modelos-guiados-el-entorno-es-la-politica, continuidad-y-observabilidad, orquestacion]\narea: Gobierno de agentes\nglyph: ◉\nhue: rgba(237,195,94,.25)\n---\n\n# Before publishing, test the real startup\n\n## The false positive of a green build\n\nA backend can compile and still fail to start. The build verifies that its steps finished; it does not prove that the production process resolves its imports, loads its configuration, opens the port and answers a request.\n\nIn a real incident, an entry file ended up with duplicated content. The deploy went ahead, but the server entered a crash loop because of repeated declarations. Recovery required fixing the code and publishing again. The problem that mattered was already in the repository: what was missing was a test able to see it before the deploy.\n\n## Three checks, three different questions\n\n### 1. Does the entry file keep a valid structure?\n\nIf a generator, a merge or an agent modifies the startup point, review the diff and run the runtime’s syntax check. Catch obvious duplications of imports, server initialization or whole blocks before calling the change done.\n\nThis review is project-specific: it is not enough to search for a repeated string and assume every repetition is an error.\n\n### 2. Does the command production uses actually start?\n\nRun the production command in a test environment with the configuration it needs. Wait for the process to open the port and make an HTTP request to a lightweight endpoint. If the process dies or the request fails, the deploy is blocked.\n\nDo not replace this check with development mode. Scripts, variables, bundlers and import paths can differ.\n\nA minimal sequence, adapted to the project, looks like this:\n\n```bash\nnpm run build\nPORT=5000 npm run start\n# In another terminal:\ncurl --fail --show-error http://127.0.0.1:5000/health\n```\n\nThe example assumes `start` and `/health` exist; use the service’s real names. The process must be able to shut down cleanly when the test ends.\n\n### 3. Does the deploy wait for a healthy response?\n\nConfigure the hosting healthcheck so a deploy is only considered ready when the backend responds. A static page or a process that started for an instant does not prove the API is operational.\n\nThe health endpoint should be cheap and represent the capability you need to serve traffic. If it depends on external services, distinguish between **process alive** and **service ready** to avoid restarts caused by a temporarily unavailable dependency.\n\n## Order matters\n\n1. Review the entry point diff.\n2. Run the build and the syntax check.\n3. Start the real command in a test environment.\n4. Test an HTTP response.\n5. Publish with a blocking healthcheck.\n6. Confirm the response from the deployed URL.\n\nEach step answers a different question. A green check does not replace the next one.\n\n## When an agent is doing the work\n\nThe task contract has to ask for concrete evidence: the command run, relevant output, the HTTP response code and the deploy result. The phrase “it works” is not enough to cross the production boundary.\n\nIf the preflight fails, the agent fixes and repeats the test. If configuration is missing that only exists in production, it records what it could verify and what is left pending for an equivalent environment; it does not turn an assumption into approval.\n\n## From local tests to published effects\n\nOperational case records reviewed on October 12, 2026 add another version of the same problem. An n8n integration had passed 56 tests, an audit and static review, but had not executed its actual HTTP node. The first real request to the already published workflow failed in its HTTP node. This was a result in that circuit and configuration, not a universal n8n defect or proof that tests were useless: the path producing the effect was missing from coverage.\n\nLater acceptance records documented two runs: change an authorized parameter, publish, read back the state and check the webhook response; then restore, **publish again** and verify that the webhook recovered its original behavior. Restoring a definition without checking the active version did not close the loop.\n\nThis evidence was read in project records, not reproduced for this editorial. It also did not cover control-hook failures or timeouts. The current distinction is useful for any handoff: **locally ready is not applied; applied is not accepted**. An immediate postflight proves a specific condition; when the objective depends on routine use, observe the agreed natural operating cycle before closing. See [the cockpit's evolution](/en/entrada/caso-orca-cockpit-multiagente).\n\n## Transferable rule\n\n**Publishing starts before the deploy button.** First you have to prove that the same program that will receive traffic can start and respond. Then the hosting has to refuse to declare a deploy successful if it does not pass that test.\n\n> Case based on a real incident. Names, dates, repositories and identifiable operational details were omitted.\n", "language": "en" }, { "slug": "amp-fabrica-agentes-cloud", "title": "Amp and the cloud agent factory", "summary": "Amp packages agent, machine, context and Git into a single surface. It does not invent multi-agent development, but it turns into a product a practice we usually still build by hand.", "type": "editorial", "order": 13, "tags": [ "amp", "orbs", "agents", "cloud", "orca", "github", "multi-model", "automations" ], "related": [ "orquestacion", "caso-orca-cockpit-multiagente", "workspaces-y-worktrees", "guia-escalado-modelos" ], "area": "Gobierno de agentes", "glyph": "◌", "hue": "rgba(87,217,232,.22)", "file": "amp-fabrica-agentes-cloud.md", "html": "Case based on a real incident. Names, dates, repositories and identifiable operational details were omitted.
\n
\n\nEditorial validity: October 12, 2026. Amp states a frontier philosophy with no commitment to backward compatibility; models, routing, pricing and features can change quickly.
\n
Amp is not interesting because it invented yet another agent capable of editing files. That space is already crowded. What is appealing is that it tries to turn everything around the agent into a product: the machine where it works, the context it keeps, the repository it modifies, the tests it runs, the agents it coordinates and the continuity needed to finish even when the user’s computer is off.
\nIn other words, Amp sells a tidy version of a factory that many teams still assemble by hand with CLIs, worktrees, persistent sessions, servers and a good deal of operational discipline.
\nA conversation can produce a good idea, but real development requires an environment. You have to clone code, install dependencies, run services, inspect CI, test the application and return reviewable changes.
\nAmp gathers those pieces around its Threads and Orbs. A Thread keeps the conversation and the work; an Orb is an isolated remote machine, created for that thread, with its own copy of the repository and its tools. It can keep running when the user closes the laptop, go to sleep when idle and wake up later with files, services and history available.
\nThe novelty is not in any single piece. It is in treating them as a single operating unit:
\nagent + context + machine + code + evidence.
\nThat combination lets you ask for something more demanding than “write this function”. You can ask it to implement the change, bring the system up, test it end to end and leave a branch or pull request with evidence attached.
\nAmp offers four built-in modes through The Dial: low, medium, high and ultra. The idea is to choose by difficulty and the cost of being wrong, not to fall in love with a model’s name.
| Mode | \nPractical reading | \n
|---|---|
low | \nSmall changes, tests and refactors with an obvious outcome | \n
medium | \nEveryday development with some ambiguity or several steps | \n
high | \nDelicate work that should arrive close to a final review | \n
ultra | \nArchitecture, migrations and open problems across several systems | \n
Behind each position, Amp can combine a main model, reasoning level, tools, instructions, subagents and an Oracle that provides a second opinion. Automatic routing changes when better models appear, while the intent of the mode stays stable.
\nThe abstraction is healthy: an organization should not rewrite its policy every time the provider ranking changes. “Use high capability when a subtle omission would be expensive” ages better than “always use model X”.
\nThat said, Amp does not force you to hand over all control. You can pin models and effort separately for the main agent, the Oracle and the subagents, and define custom modes through plugins.
\nThe Dial is customizable, but a Thread keeps the mode selected for its first message: switching requires a new thread. Choose the effort before starting.
\nAmp distinguishes between specialized subagents and full agents running in other Threads.
\nInternal subagents handle searches, research, reading previous conversations and hard questions for the Oracle. They work with a separate context window and return a summary to the main agent. They keep the central thread clean, although they have clear limits: they do not talk to each other and cannot be steered mid-task.
\nDelegation between full agents is more ambitious. One agent can start another Thread in an Orb, hand it instructions or files and keep working while it waits for the result. Each thread gets its own conversation, working copy and machine. That enables real fan-out: several investigations, browsers, fixes or projects moving forward in parallel.
\nThe isolation is deliberate. Uncommitted files and changes do not magically appear in the other environments; they have to be transferred or merged explicitly. That friction prevents a fair amount of chaos, but it does not remove the need for a good coordinator.
\nAmp and Orca overlap, but they are not exactly the same product.
\n| Dimension | \nCockpit with Orca and CLIs | \nAmp | \n
|---|---|---|
| Unit of work | \nSession, terminal and worktree managed by the user | \nThread with a working copy and an isolated Orb | \n
| Infrastructure | \nLocal machine, WSL, SSH and your own servers | \nCloud Orbs, local execution or your own runners | \n
| Model selection | \nExplicit and granular per tool | \nRouting by difficulty, with the option to pin it | \n
| Coordination | \nFlexible, visible and hand-built | \nBuilt-in delegation between subagents and Threads | \n
| Continuity | \nDepends on the processes and hosts you manage | \nThe Orb keeps working and pauses automatically | \n
| GitHub | \nCredentials and flow from the local environment | \nGitHub App, short-lived tokens, branches, PRs and CI built in | \n
| Platform dependence | \nLower: interchangeable pieces | \nHigher: Orbs, Threads and coordination live in Amp | \n
Orca works especially well as a cockpit. It lets you watch several tools, deliberately choose which CLI and which provider fills each role, step into sessions and keep control over the infrastructure.
\nAmp works more like a managed factory. It delivers disposable remote environments, continuity, isolation and a direct path from the brief to a PR. It cuts operational work in exchange for accepting more of the platform’s decisions and infrastructure.
\nThere is no universal winner. There are two different preferences: governing every piece or buying an execution unit that is already solved.
\nThe GitHub integration is designed to work without spreading permanent tokens inside each Orb. Amp uses a GitHub App and hands out short-lived credentials when Git or gh need to talk to it. It can clone private repositories, create branches and pull requests, check CI and sign commits; protection rules still apply as if the user were acting.
It is a reasonable foundation for teams, but the caution stays the same: start with selected repositories, minimal permissions and protected branches. An agent having an isolated machine does not mean it should get access to the whole organization.
\nAmp automations let a Thread wake up once or on a schedule while keeping its history. It can check errors every hour, watch a long process, verify CI after a change or remind you to retire a feature flag.
\nThat is more expressive than an isolated cron job because the agent picks up earlier decisions and evidence. It is also riskier if the brief is vague or the permissions are broad. An agentic automation needs:
\nContinuity does not replace governance. It makes it more important.
\nThe current pricing combines monthly tiers and pay-as-you-go, separating agent and tool usage from the Orb allowance. Orbs are metered by the minute, larger sizes use more allowance, and paused Orbs cost nothing.
\nCompatible keys and subscriptions can be connected, but check the effective routing. A Claude subscription covers Claude Code mode, not Amp’s own modes. With ChatGPT, uncovered calls and tools still consume Amp credits; the subscription does not cover the Orb either. Mode-specific details.
\nTo evaluate the product, comparing price per token is not enough. You have to measure:
\nA cheap agent that needs three rounds is not necessarily economical. An Orb that costs cents can save an hour of setup or, if it is oversized and poorly controlled, add spend without improving the result.
\nAmp should not replace a multi-agent environment that already works overnight. A useful trial is bounded:
\nThe first good fits are self-contained features that end in a PR, long investigations you would rather not run locally and parallel tasks across repositories. Production, broad secrets and automations with the ability to mutate things should come after validating real behavior.
\nAmp does not remove the need to think about how agents work. It makes that visible as a product.
\nIts strongest contribution is not promising a miracle model, but recognizing that the quality of agentic development depends as much on the environment as on intelligence: isolation, continuity, tools, permissions, coordination and evidence.
\nFor someone who already built a hand-made cockpit, Amp may feel less like a revolution and more like industrialization. The question is not whether it can write code. The question is how much control is worth keeping and how much operational work is worth delegating to the platform.
\nA tracking guide for choosing which models to test
\nInterface walkthrough from October 3, 2026 · Documentation reviewed October 12, 2026. On the latter visit, the main page showed usage data through October 11.
\nA ranking is useful when it helps you make a concrete decision: which model is worth testing, for what work and at what cost if you get it wrong. The problem arises when a position becomes a conclusion that the measurement never promised.
\nOpenRouter brings together signals of real usage, spend, speed and capability evaluations. This guide proposes a tour of its sections, identifying what each one counts and turning them into a repeatable tracking process. First we choose what to observe; then we check whether that signal improves our work.
\nThe main tour covers the thirteen subsections of Text. It also includes the other Rankings tabs and their units. Walkthrough names and controls correspond to October 3; the numerical examples are illustrative and do not present current winners. [1]
\nBefore comparing two models, write down five things: unit, population, time window, aggregation and conditions. This minimal record prevents sweeping conclusions from small numbers.
\nUnit: tokens, requests, dollars, seconds or benchmark points. Changing the unit changes the question.
\nPopulation: all eligible traffic, a classified sample, a language, an application or a specific test.
\nWindow: a full day, seven days, thirty days or the date of an experiment. The access date does not replace the date of the data.
\nAggregation: sum, share, change, median or composite index. An average and a median can tell different stories.
\nConditions: version, variant, provider, reasoning effort, cache, tools and harness. The same name can cover different configurations.
\nOpenRouter observes the traffic that passes through its platform and enters each public dataset. That population alone does not let you infer a lab's worldwide market share, its number of customers or its entire business. Private data and documented exclusions also matter. [2]
\nThis is the historical overview of weekly token volume. It lets you see which models sustain activity, which appear suddenly and how the total size of traffic changes. The visualization highlights nine models and groups the rest under Others. The unit adds input and output; each variant is treated separately. [1]
\nHow to track it: compare several weeks, record the scale and look at the total as well as each color. A linear scale helps put absolute differences in perspective; a logarithmic scale makes orders of magnitude easier to see. Changing the scale does not change the data, but it does change their appearance.
\nWhat to avoid: interpreting more tokens as more people or more productivity. An agent that rereads a repository, chains turns together or generates long responses can produce a lot of volume. Tokenizers also do not segment text identically across providers. [7]
\nThe table lets you rank that usage and choose open models, closed models or all models. Today, This Week and This Month cover 1, 7 and 30 full days respectively, ending in UTC. New & Trending compares the last seven days with the previous seven; it requires one million tokens in the current window and may place up to five new models first. [1]
\nGrowth compares volumes: going from 10 to 15 million tokens represents a 50% increase. It does not mean gaining fifty percentage points of share. And new indicates the lack of a comparable prior baseline, not an infinite growth rate.
\nHow to track it: keep a weekly view for the trend and a monthly view for persistence. Separate launches, free variants and stable versions. An openness filter changes the set being compared; it does not certify licenses, usage permissions or model quality.
\nThis section brings the ranking closer to concrete work. It lets you switch between Share of spend and Share of tokens. Tasks are inferred from a sample of prompts, and the interface says it adjusts the figures for sampling. The Auto Router documentation associates the spend view with a rolling seven-day window. [3] [4]
\nThe rectangle map, or treemap, contains two levels that should be read separately. A task's area indicates how much it represents within the total for the selected metric. When you open it, the list shows each model's share within that task. The size of Classification and a model's percentage in Classification have different denominators.
\nExample: if a task accounts for 10% of spend and a model accounts for 20% of that task's spend, its portion of the total would be 2%, provided both percentages share the same population and window. Reading the 20% as a share of all OpenRouter would inflate the interpretation tenfold.
\nColors distinguish four families. There were 29 labels at the time of review; preserving their names makes them easier to find even if their position in the chart changes:
\nGeneral: Classification, Content Writing, Roleplay & Fiction, Q&A & Knowledge, Conversation, Research & Reports, Customer Support, Summarization, Security Audit, Math, Finance & Trading, Translation and DevOps
\nAgent: Workflow Execution, Multi-step Planning, Tool Dispatch, Web Search and Memory Extraction
\nCode: Code Generation, Debugging, File I/O, Code Review, Shell Execution, Frontend & UI, Repo Scanning, DevOps & Config and SQL & Database
\nData: Data Extraction and Data Transformation
\nHow to track it: choose the task closest to your work and switch between spend and tokens. If a model takes up much more space in spend, investigate price, length, reasoning and the mix of work. If it gains in tokens, investigate volume and free variants. Neither difference identifies, by itself, which responses were correct.
\nThe classification is an estimate of the prompt's intent. A programming session may move through planning, file reading, search, generation and review. Avoid treating each box as a separate industry or adding up their positions to invent an overall score.
\nMethodological limit: the interface explains that deltas compare with the previous window, but does not spell out all the details there. Before publishing a change as percentage points, check the specific definition. These views also do not publish a complete account of sample size, classifier accuracy, confidence intervals and the accounting treatment of spend.
\nThere is another relevant difference for anyone who wants to automate tracking: the classifications API documents shares of requests and tokens, excludes other from the denominator and ranks models by requests. Those fields do not automatically replace the treemap's spend share. A similar name does not guarantee the same calculation. [5]
\nHere the question shifts to the observed cost of an agent session. The unit is USD per session and the summary statistic is the median, separated by harness. The reviewed interface showed Hermes Agent, Claude Code, Kilo Code and Codex, with ranges of 1, 2 to 9, 10 to 49 and 50 or more turns.
\nThe tooltip specifies a 30-day window, paid usage and a logarithmic scale. A session is attributed to a model when that model processed at least 80% of its tokens. The dataset reference confirms that applications are not mixed together, that medians are published and that the snapshot is updated weekly. [1] [6]
\nHow to track it: fix the harness first, then choose a comparable range. The median describes the center of the distribution: half the sessions fall below it and the other half above it. It does not show how much the tail of difficult sessions costs, nor is it enough to budget for a full month.
\nA cheap session may have been simple, short, aborted or unsuccessful. A long one may have completed valuable work. To decide in your own environment, add success, retries and review time. The 80% rule also limits how you can interpret workflows that spread a lot of work across several models. The exact session boundaries and publication thresholds are not specified in the reference consulted.
\nThis groups by model author and counts text requests. Absolute shows quantities; Percentage shows each author's portion of the period's total. The model author is not necessarily the company serving the endpoint. [1]
\nHow to track it: look at both views. If an author goes from 100 to 120 requests while the total goes from 200 to 300, its volume grows by 20% and its share falls from 50% to 40%. Both observations are compatible.
\nThis section helps identify changes in the composition of traffic. Explaining the cause requires more evidence: launches, availability, prices, integrations or routing decisions. Two curves moving at the same time is not enough. Also keep the date of the observed point; the summary text and the chart may refer to different cutoffs.
\nThis is the section for comparing evaluation results. The reviewed selector brought together thirteen metrics from three families: evaluations run by OpenRouter, Artificial Analysis indices and Design Arena ratings. Keep that provenance alongside the score. [2]
\nGPQA Diamond, τ²-Bench Airline and VGI-Bench: the panel presents accuracy. For GPQA Diamond and VGI-Bench, the tooltip specifies median accuracy across providers, measured by OpenRouter. Each test has its own protocol; open its detail page before interpreting the percentage.
\nIntelligence Index, Coding Index and Agentic Index: these are composite indices from Artificial Analysis. They are useful for an initial general, coding or agent shortlist. An index value should not automatically be read as the percentage of tasks solved.
\nCode Categories, UI Component, Game Development, Data Visualization, 3D, Image and SVG ELO: these are Design Arena ratings for head-to-head comparisons. Their scale is relative to the evaluation system and its participants; 1,500 Elo points do not equal 75% quality.
\nIn an accuracy evaluation, the denominator is the cases evaluated under a protocol. A composite index involves several tests and their combination rules. Elo involves comparisons and relative results. These methodologies answer different questions: they should not be averaged as if they shared a scale.
\nGPQA Diamond uses multiple-choice science questions. Its current page presents run variability and cost, and publishes downloadable snapshots. The 90-day protocol described in the earlier review could not be reconfirmed in the page accessible on October 12: do not assume it remains the current rule. The widget and detail table may use different representations; cite the precise view and snapshot your figure comes from. [23]
\nThe following VGI-Bench description is retained as an October 3 record: its page could not be reconfirmed on October 12. Do not treat these thresholds as a current contract.
\nVGI-Bench stands for Video General Intelligence Bench and evaluates understanding of long videos. OpenRouter's implementation supplies the video and a multiple-choice question in a single turn, with temperature 0, and grades the final letter. It uses a public set of 439 questions, requires at least 395 answers for a run to be included and considers the last 90 days. It is useful for investigating temporal and audiovisual understanding; its accuracy is not a video-generation score. [21]
\nτ²-Bench Airline evaluates customer service with a simulated user and airline tools. Success requires the expected final database state and the required messages, with no partial credit. The detail page fixes the simulator, limits a run to 200 steps and aggregates tests from 90 days, weighted by tasks, with a minimum of 45 per model-provider pair. Its main result uses default routing if available; otherwise, the median across providers. That rule from the detail page should not be generalized to the entire widget. [22]
\nThe economic axis also changes. The chart offers Weighted Avg Input Price, Input List Price and Avg Price Per 100 Requests. The first two views are expressed per million input tokens; the third uses requests. The effective price on detail pages incorporates observed usage, where caching and discounts may cause it to differ from the published price. [9]
\nHow to track it: fix the benchmark and price axis before comparing. Input price leaves out output and other components of your bill; the average per request depends on the size of those requests. Neither automatically equals cost per solved task.
\nShow Pareto helps identify options that are not simultaneously outperformed on both selected dimensions. If two candidates have the same score and one costs less, the more expensive one is dominated in that chart. That conclusion may change when you add latency, reliability, permissions or performance in Spanish. The visible frontier also does not represent models the chart did not include.
\nThe View all benchmarks link leads to a broader catalog with Agents, Media, Artifacts, Reasoning and Search families. Its experiments may also evaluate tools, search engines and budgets. Review the specific run: the catalog's latest overall date does not retrospectively update every card. [8]
\nThis has two modes: Highest throughput and Lowest latency. The eligibility tooltip admits models with at least 100,000 requests in the last 24 hours. That threshold describes who can appear; on its own, it does not specify how all performance values were aggregated.
\nThroughput expresses generation speed in tokens per second. Latency requires reading its definition in the corresponding view: waiting for the first token and receiving the complete response are different experiences. OpenRouter's performance pages distinguish TTFT and latency measures; do not assume that every panel uses the same percentile or window. [10] [11]
\nHow to track it: compare the same endpoint, context and configuration. Sustained speed matters for a long response; the initial wait may dominate a brief interaction. For an agent, also add tools, turns and retries. A model that writes quickly may take longer to finish the work.
\nDo not automatically attribute one provider's best performance to every provider serving that model. If the view does not state the percentile, window or weighting across providers, retain that limitation in the comparison.
\nThis lets you segment by natural language and switch between absolute quantity and percentage. Language data comes from extrapolated samples; the public reference treats it as weekly estimates. Share is interpreted within the selected language, not across all languages. [7]
\nHow to track it: for a product in Spanish, look at Spanish even if English dominates the overall picture. Then test real tasks: understanding instructions, register, regional expressions, extraction and the faithfulness of responses. Traffic in a language does not, by itself, evaluate quality in that language.
\nA conversation may mix languages, code and quotations. Without a published definition of the classifier and its error, small changes deserve caution. Extrapolation provides a volume estimate; it does not remove selection bias or guarantee that the sample represents all use of Spanish.
\nFor automation: category and language_type use weekly estimates, reject period=day, and cannot combine with exact modality/context filters or each other. The last week can extend beyond end_date; monthly grouping assigns each week to its starting month. Monthly boundaries are therefore approximate. [7]
This applies a similar approach to programming languages, with Python as the initial selection at the time of review. It shows token usage in a classified sample. The absolute and percentage views retain the segment's unit, which is not a problem-solving rate. [1] [7]
\nHow to track it: compare your repository's language and cross-reference it with Coding Index or a relevant coding benchmark. That builds a candidate list. Your own test should include understanding the project, a change with tests, a bug and a diff review.
\nA model appearing frequently in Python may reflect an application's integration or the volume of a heavy user. Nor does it identify the framework, difficulty, version or final outcome. A change in share warrants investigation; replacing the model requires verifying an improvement.
\nThis counts requests by the observed length of prompt and completion. The selector offers less than 1K, 1K to 10K, 10K to 100K, 100K to 1M and 1M to 10M tokens. The chart's unit is requests, with an absolute or percentage view. [1]
\nHow to track it: choose the range of your workloads. Seeing usage with long inputs and outputs may indicate that a model is worth testing for long documents or large repositories. The advertised maximum window requires a separate check of the model's detail page.
\nNominal capacity, the length actually used and the quality of information retrieval are three different measurements. To validate long context, use relevant data placed in different parts of the material and verify relationships between them. Fitting within the limit does not demonstrate understanding.
\nThis presents the distribution of tool activity across models. The public tool_calling filter identifies requests in which at least one call was recorded; that does not let you automatically equate requests with the number of individual calls. When exporting data, preserve the field counted by that view. [7]
\nHow to track it: use it to identify models present in workflows with tools. Then measure tool selection, valid arguments, interpretation of results, error recovery and respect for permissions.
\nMore activity may accompany a useful agent or an unproductive loop. It may also change because of how the harness divides an operation. The chart's share does not reveal what percentage of calls succeeded or what percentage of all that model's traffic used tools.
\nWithin Text, Images shows images processed by models and lets you switch between volume and share. It is important to distinguish this block from the top-level Image tab, which focuses on image generation. The dataset separately documents image input and image_output output. [1] [7]
\nHow to track it: to understand screenshots, invoices or charts, look at multimodal usage and build concrete reading tests. To generate illustrations, choose the generation tab and its corresponding evaluations.
\nA request may contain more than one image. Image counts, requests with images and image tokens are not interchangeable. And processing many images does not demonstrate accuracy in OCR, counting, spatial interpretation or visually following instructions.
\nThis ranks applications and agents that participate in public usage attribution. Volume is expressed in tokens, and the selector lets you change the period. Hidden or private apps are excluded; the dataset may consolidate aliases of the same application. [2]
\nHow to track it: cross-reference it with model movements. A large integration can alter demand without the model having changed. The app adds instructions, tools, memory and routing, so it should be evaluated as a system.
\nThe ranking does not count installations, active users or all of an application's activity outside OpenRouter. Nor do all controls called trending share a formula: the apps API describes excess absolute growth relative to three previous periods, while the model ranking compares percentage growth between two windows. [2]
\nThe top bar lets you leave Text. In Image, Video, Speech, Embeddings, Rerank and Transcription, tables are ranked by requests and the chart above may offer another unit. Batch starts with subrequests and also allows ranking by tokens. Check which of the two components changes with each selector. [13] [14] [15] [16] [17] [18] [19]
\nImage: the chart switches between requests and images. A request that returns several images counts once in the requests table.
\nVideo: requests or hours in the chart. A request count does not tell you the clips' total duration, resolution or cost.
\nSpeech: requests in the reviewed view. For your own test, audio duration, intelligibility, pronunciation and adherence to style also matter.
\nEmbeddings: requests or tokens in the chart. Also evaluate retrieval with your corpus; more volume does not demonstrate better semantic neighbors.
\nRerank: requests or documents. One request may reorder many documents, so the two volumes answer different questions.
\nTranscription: the chart switches between requests and characters; the table keeps requests. It assesses speech-to-text transcription usage. To choose, measure errors on representative audio, accents and acoustic conditions.
\nBatch: the Subrequests or Tokens selector changes both the chart and the table. It offers a filter for text, embeddings or all modalities. Subrequests count the work inside batches, not the number of batches. Add completion time, failures and cost when comparing alternatives.
\nThe first six tabs include Top Models, Leaderboard and Market Share. The latter retains requests by author. Batch includes the first two. Not every modality replicates Text's thirteen sections.
\nThe tables retain period controls such as Today, This Week, This Month and New & Trending. A control being available is not enough to attribute all the text ranking's thresholds and rules to it; check that modality's methodological note before reusing its calculation.
\nConfusing share and growth. Going from 10% to 15% means gaining 5 percentage points and growing 50% relative to the initial share. State which one you calculated.
\nReading a share without its total. A segment may gain share while its volume falls. Save both when available.
\nComparing different cutoffs. A partial day, a UTC close and a classification week do not describe exactly the same period.
\nTreating absence as zero. A model outside the visible top group, without enough data or without a published score may simply be unobservable in that view.
\nExplaining correlations as causes. A launch, a free offer or a routing change remains a hypothesis until there is additional evidence.
\nThe most important limitation runs throughout this guide: observed usage helps choose candidates; fitness for our work is established through results. OpenRouter also recommends checking general benchmarks against real prompts and cost per completed task. [12]
\nThere is no need to look at every panel every day. Keep a stable question and use the sections that provide evidence to answer it.
\nDefine the work. For example, reviewing changes to a Python backend with tests available and no production access. Agree on what counts as success before seeing the responses.
\nChoose the segment. Open Code Review, Programming in Python and the usual context range. Use the overall ranking as context.
\nSave the observation. Record the access date, data date, unit, filter, period, exact variant and source. If using the API, also preserve the metadata.
\nBuild a shortlist. Include the current model, a lower-cost candidate and another that promises greater capability. A usage spike is enough to enter the test, not to win it.
\nSet comparable conditions. The same set of cases, context, tools, budget and evaluation criteria. Record provider, effort and limits; document any necessary differences.
\nMeasure the complete outcome. Success, relevant errors, attempts, time to a usable result, total cost and human review. Count failures and abandoned attempts too.
\nRepeat where there is variation. Use multiple attempts when appropriate, keep difficult cases and treat small differences cautiously. Separate consistent improvements from a single good run.
\nMake a reversible decision. Keep the current model, test in a bounded environment or replace it. Define what deterioration would justify returning to the previous model and when to review again.
\nThe internal economic metric can be as concrete as spend across all attempts divided by accepted tasks. For example, USD 12 for 30 accepted tasks gives USD 0.40 per accepted task. A second model that spent USD 9 but completed only 15 comes to USD 0.60. The price per token did not make that difference visible.
\nHuman review cost should be recorded separately and, if it matters for the decision, incorporated using an explicit criterion. There is no need to pretend to have precision that does not yet exist: a consistent record is worth more than a very exact figure whose denominator changes every week.
\nA useful record can fit in ten lines: objective; cases and acceptance criterion; date; model and variant; provider; harness and tools; configuration; successes over attempts; cost and time; decision. For public tracking, add the exact OpenRouter view and its unit.
\nIf a panel does not publish sample size, uncertainty, window or the treatment of caching and discounts, write not published rather than filling the gap by intuition. The historical State of AI study and a current panel may use different taxonomies or methods; an explanation from 2025 should not automatically be applied to the 2026 interface.
\nFor republishing data, OpenRouter allows reuse with attribution under CC BY 4.0. Save the snapshot, cite the source and its actual date, and identify your transformations. Documentation response examples describe the format: their figures are not current observations. [2] [20]
\nThe value of Rankings lies in narrowing the search space. It helps identify where activity is growing, which tasks attract investment and which alternatives deserve evaluation. The benefit appears when that observation leads to a well-defined test.
\nFor Golden Path, the final criterion is practical: choose the combination of model, provider and harness that solves the work with sufficient quality, cost and control. Preserving the evidence behind that choice makes it possible to revisit it when the catalog changes, without starting from scratch or chasing every new first-place model.
\nOriginal walkthrough and sources dated October 3, 2026. On October 12, Rankings, Data API, token and session datasets, task classification and τ²-Bench Airline were reconfirmed, and the current GPQA page was reviewed. Dynamic controls and the other pages retain the original date. Rankings links open dynamic views; their values may change after this review. The reference screenshots provided for the guide cover Text navigation and Top models by task.
\nMany steps in an AI application do not need another paragraph. They need to know what to do next: which team to send a request to, whether a claim is supported, which candidate to review first or whether it is worth calling a more expensive model.
\nJev 1.13, by TypeSafe, is designed for that kind of decision. It takes text or structured state and returns typed answers, not free prose. The System One documentation distinguishes three primitives:
\n| Primitive | \nQuestion | \nAnswer | \n
|---|---|---|
| Choice | \nWhich of these options best describes the case? | \nOne option and probabilities | \n
| Score | \nWhere does the case fall on a defined scale? | \nA score over the configured levels | \n
| Noul | \nIs this condition met? | \nA probability between 0 and 1 | \n
The application defines the options and criteria. Jev judges a state within that frame; the code decides which action follows, with its own rules and permissions.
\nAn incoming request might go to technical support, billing or manual review. If the choice is ambiguous, the application can ask Jev for a category and send low-confidence cases to a person. The same idea works for classifying incidents or separating useful signals from noise in a queue.
\nWhen there is already a bounded list of options, Jev can score which ones look most relevant: retrieved memories, alerts or tasks to review. It pays to shrink the set with cheap filters first; asking for a decision over the whole base increases cost and noise.
\nA generative LLM can extract data from a conversation, but writing a claim does not make it a fact. A gate can assess whether there is evidence, whether the data looks durable or whether it contradicts what is already recorded. Mutations still go through the system’s validation and idempotency.
\nIf the task only requires choosing between known routes, you may not need to call a long-reasoning model. Jev can help route clear cases and leave the hard ones for another model or a human review. The real savings are measured alongside routing errors: making a call cheaper at the cost of losing important cases would be a terrible trade.
\nA high probability does not prove that an individual answer is correct. TypeSafe describes calibration as a property measured over sets of predictions, not as a per-case guarantee. You have to test with domain data, real languages and hard examples before choosing thresholds.
\nAlso, Score uses the configured scale: if the criteria have five levels, its raw value should not be read as a number between 0 and 1 without normalizing it. And a well-formed decision does not, on its own, authorize a send, a write or a publication.
\nThe useful architecture usually has four pieces: relevant state → bounded question → typed answer → deterministic rule. Decisions are logged so hits and misses can be compared; when the provider fails, the application picks an explicit fallback.
\nIn an interactive fiction v2 we tried Jev as part of a Director that watches scenes and decides which relationships, facts, themes and promises leave consequences. There the question was not “write a better scene”, but “what actually changed and who can remember it?”.
\nThe design, the fixes found during testing and their limits are in the narrative Director case. It is one example of application; routing, scoring and gates are other starting points that need their own evaluation.
\n", "headings": [ { "label": "A different question from “write me an answer”", "depth": 2, "id": "a-different-question-from-write-me-an-answer" }, { "label": "Four places where it makes sense to try it", "depth": 2, "id": "four-places-where-it-makes-sense-to-try-it" }, { "label": "Routing and classification", "depth": 3, "id": "routing-and-classification" }, { "label": "Scoring and ranking candidates", "depth": 3, "id": "scoring-and-ranking-candidates" }, { "label": "Gates before persisting", "depth": 3, "id": "gates-before-persisting" }, { "label": "Escalation between models", "depth": 3, "id": "escalation-between-models" }, { "label": "Confidence is not permission", "depth": 2, "id": "confidence-is-not-permission" }, { "label": "Which use turned out to be concrete", "depth": 2, "id": "which-use-turned-out-to-be-concrete" } ], "raw": "---\nslug: jev-decisiones-estructuradas\ntitle: \"Jev: small decisions inside large systems\"\ntype: concept\norder: 13\nsummary: \"What a structured-decision model does and where it belongs: routing, classification, scoring and gates before state changes.\"\ntags: [jev, decisions, routing, scoring, agents, architecture]\nrelated: [caso-jev-director-narrativo, modelos-guiados-el-entorno-es-la-politica, orquestacion]\narea: Gobierno de agentes\nglyph: ◈\nhue: rgba(168,106,255,.24)\n---\n\n# Jev: small decisions inside large systems\n\n## A different question from “write me an answer”\n\nMany steps in an AI application do not need another paragraph. They need to know **what to do next**: which team to send a request to, whether a claim is supported, which candidate to review first or whether it is worth calling a more expensive model.\n\n[Jev 1.13](https://openrouter.ai/typesafe/jev-1.13), by TypeSafe, is designed for that kind of decision. It takes text or structured state and returns typed answers, not free prose. The [System One documentation](https://docs.typesafe.ai/concepts/system-one) distinguishes three primitives:\n\n| Primitive | Question | Answer |\n| --- | --- | --- |\n| **Choice** | Which of these options best describes the case? | One option and probabilities |\n| **Score** | Where does the case fall on a defined scale? | A score over the configured levels |\n| **Noul** | Is this condition met? | A probability between 0 and 1 |\n\nThe application defines the options and criteria. Jev judges a state within that frame; the code decides which action follows, with its own rules and permissions.\n\n## Four places where it makes sense to try it\n\n### Routing and classification\n\nAn incoming request might go to technical support, billing or manual review. If the choice is ambiguous, the application can ask Jev for a category and send low-confidence cases to a person. The same idea works for classifying incidents or separating useful signals from noise in a queue.\n\n### Scoring and ranking candidates\n\nWhen there is already a bounded list of options, Jev can score which ones look most relevant: retrieved memories, alerts or tasks to review. It pays to shrink the set with cheap filters first; asking for a decision over the whole base increases cost and noise.\n\n### Gates before persisting\n\nA generative LLM can extract data from a conversation, but writing a claim does not make it a fact. A gate can assess whether there is evidence, whether the data looks durable or whether it contradicts what is already recorded. Mutations still go through the system’s validation and idempotency.\n\n### Escalation between models\n\nIf the task only requires choosing between known routes, you may not need to call a long-reasoning model. Jev can help route clear cases and leave the hard ones for another model or a human review. The real savings are measured alongside routing errors: making a call cheaper at the cost of losing important cases would be a terrible trade.\n\n## Confidence is not permission\n\nA high probability does not prove that an individual answer is correct. TypeSafe describes calibration as a property measured over sets of predictions, not as a per-case guarantee. You have to test with domain data, real languages and hard examples before choosing thresholds.\n\nAlso, *Score* uses the configured scale: if the criteria have five levels, its raw value should not be read as a number between 0 and 1 without normalizing it. And a well-formed decision does not, on its own, authorize a send, a write or a publication.\n\nThe useful architecture usually has four pieces: **relevant state → bounded question → typed answer → deterministic rule**. Decisions are logged so hits and misses can be compared; when the provider fails, the application picks an explicit fallback.\n\n## Which use turned out to be concrete\n\nIn an interactive fiction v2 we tried Jev as part of a Director that watches scenes and decides which relationships, facts, themes and promises leave consequences. There the question was not “write a better scene”, but “what actually changed and who can remember it?”.\n\nThe design, the fixes found during testing and their limits are in [the narrative Director case](/en/entrada/caso-jev-director-narrativo). It is one example of application; routing, scoring and gates are other starting points that need their own evaluation.\n", "language": "en" }, { "slug": "gentle-ai-engram-memoria-y-proceso", "title": "Gentle AI and Engram: memory and process for coding agents", "summary": "What an environment configurator contributes and what persistent memory solves when agent work spans sessions, tools and projects.", "type": "editorial", "order": 14, "tags": [ "gentle-ai", "engram", "memory", "agents", "governance", "workflow" ], "related": [ "orquestacion", "continuidad-y-observabilidad", "modelos-guiados-el-entorno-es-la-politica" ], "area": "Gobierno de agentes", "glyph": "◈", "hue": "rgba(168,106,255,.24)", "file": "gentle-ai-engram-memoria-y-proceso.md", "html": "\n\nDocumentation reviewed: October 12, 2026. Integration capabilities vary; this review does not imply a new environment test.
\n
An agent can complete a task and, in a new session, ask again about decisions the team already made. It can also recall an obsolete rule, apply a heavyweight process to a tiny change, or deliver code without verifiable evidence. These are different failures: continuity, context freshness and proof of the result.
\nThe Gentleman Programming ecosystem offers two related pieces. Gentle AI configures the coding agents you already use with memory, workflow, skills and review components. Engram supplies persistent memory that different agents can query. One organizes the environment; the other carries knowledge across sessions. You can evaluate either without adopting the whole ecosystem.
\nGentle AI is a configurator, not a model or a new agent. It prepares integrations for tools such as Claude Code, OpenCode and Codex, with components and presets that let you choose how much governance the environment needs. Its intended usage guide describes Organic Driven Development (ODD) as the everyday path: inspect the project, keep understood changes lightweight, verify the outcome and leave a recoverable feature record when work grows.
\nThat proportionality matters. If fixing a label requires the same ritual as migrating a module, the team eventually ignores the ritual. For larger work, a feature record and current progress let another session resume without reconstructing everything from commits and chats.
\n| Layer | \nQuestion it answers | \nExpected evidence | \n
|---|---|---|
| Configuration | \nWhich tools and rules does this agent have? | \nInstalled components and environment diagnosis | \n
| Process | \nHow is this task explored, implemented and resumed? | \nScope, decisions and current state | \n
| Verification | \nWhich behavior was checked? | \nRelevant tests, review or checks | \n
| Memory | \nWhat should the next session retrieve? | \nObservations with context and project | \n
The current documentation specifies test-first when a relevant runnable test exists; otherwise, explain the exception and verify another way. RDD defaults to on with opt-out, respects explicit disabling, and binds review to a frozen candidate. Automatic review is reserved for high-risk candidates; capabilities differ by integration. This does not authorize commit, push or release. A tidy workflow does not turn a superficial check into evidence.
\nEngram is a local memory system for agents, built as a Go binary with SQLite and full-text search. It exposes a CLI, MCP server, HTTP API and TUI. An agent can save and search observations about decisions, discoveries, fixed bugs and project conventions. The documentation describes curated memory, not an indiscriminate log of every conversation.
\nSuppose a portal treats long CRM IDs as strings to avoid precision loss in JavaScript. After a session, saving “CRM IDs remain strings in the API, sorting and exports; inspect the adapter before normalizing them” is more useful than retaining a hundred messages where the subject appeared. The next session can retrieve the decision, check that it still matches the code and proceed.
\nThat last check is essential. A memory is a clue with provenance, not a higher-priority instruction or the repository's source of truth. If the contract changes, update or replace the observation. Engram keeps local SQLite authoritative: Git Sync exports portable chunks, while optional Engram Cloud provides project-scoped replication and shared access. Sharing memory also means deciding who can write, what may be stored and how conflicting decisions are resolved.
\nWhen a coordinator delegates to different models, each worker should receive only the context it needs: goal, boundaries, repository state and relevant decisions. Engram can help retrieve those decisions; Gentle AI can provide repeatable configuration and workflow. Coordination and permission to change things still belong to the system directing the work and the people accountable for it.
\nA practical pilot would be:
\nThe number of saved memories is a poor success measure. The useful signal is whether the next person or agent makes a sound decision with less reconstruction and visible evidence.
\nPersistent memory has its own debt: obsolete information that sounds persuasive. Process can become bureaucracy when applied without regard to scale. Keep memory, current state, proof and permission separate. An observation alone does not authorize a production write; a checklist does not prove the right command ran.
\nGentle AI and Engram are worth examining when the real pain is repeatedly explaining context, losing decisions between tools or struggling to resume delegated work. Testing them separately with simple measures can give the environment continuity without turning every task into a ceremony.
\n", "headings": [ { "label": "The problem does not begin when the agent makes a mistake", "depth": 2, "id": "the-problem-does-not-begin-when-the-agent-makes-a-mistake" }, { "label": "Gentle AI: configuring how work gets done", "depth": 2, "id": "gentle-ai-configuring-how-work-gets-done" }, { "label": "Engram: remember decisions instead of recording everything", "depth": 2, "id": "engram-remember-decisions-instead-of-recording-everything" }, { "label": "A sweet spot for a multi-agent environment", "depth": 2, "id": "a-sweet-spot-for-a-multi-agent-environment" }, { "label": "The limit that determines whether it helps", "depth": 2, "id": "the-limit-that-determines-whether-it-helps" } ], "raw": "---\nslug: gentle-ai-engram-memoria-y-proceso\ntitle: \"Gentle AI and Engram: memory and process for coding agents\"\ntype: editorial\norder: 14\nsummary: \"What an environment configurator contributes and what persistent memory solves when agent work spans sessions, tools and projects.\"\ntags: [gentle-ai, engram, memory, agents, governance, workflow]\nrelated: [orquestacion, continuidad-y-observabilidad, modelos-guiados-el-entorno-es-la-politica]\narea: Gobierno de agentes\nglyph: ◈\nhue: rgba(168,106,255,.24)\n---\n\n# Gentle AI and Engram: memory and process for coding agents\n\n> Documentation reviewed: October 12, 2026. Integration capabilities vary; this review does not imply a new environment test.\n\n## The problem does not begin when the agent makes a mistake\n\nAn agent can complete a task and, in a new session, ask again about decisions the team already made. It can also recall an obsolete rule, apply a heavyweight process to a tiny change, or deliver code without verifiable evidence. These are different failures: continuity, context freshness and proof of the result.\n\nThe [Gentleman Programming](https://gentlemanprogramming.com/) ecosystem offers two related pieces. **Gentle AI** configures the coding agents you already use with memory, workflow, skills and review components. **Engram** supplies persistent memory that different agents can query. One organizes the environment; the other carries knowledge across sessions. You can evaluate either without adopting the whole ecosystem.\n\n## Gentle AI: configuring how work gets done\n\n[Gentle AI](https://github.com/Gentleman-Programming/gentle-ai) is a configurator, not a model or a new agent. It prepares integrations for tools such as Claude Code, OpenCode and Codex, with components and presets that let you choose how much governance the environment needs. Its [intended usage guide](https://github.com/Gentleman-Programming/gentle-ai/blob/main/docs/intended-usage.md) describes **Organic Driven Development (ODD)** as the everyday path: inspect the project, keep understood changes lightweight, verify the outcome and leave a recoverable feature record when work grows.\n\nThat proportionality matters. If fixing a label requires the same ritual as migrating a module, the team eventually ignores the ritual. For larger work, a feature record and current progress let another session resume without reconstructing everything from commits and chats.\n\n| Layer | Question it answers | Expected evidence |\n| --- | --- | --- |\n| Configuration | Which tools and rules does this agent have? | Installed components and environment diagnosis |\n| Process | How is this task explored, implemented and resumed? | Scope, decisions and current state |\n| Verification | Which behavior was checked? | Relevant tests, review or checks |\n| Memory | What should the next session retrieve? | Observations with context and project |\n\nThe [current documentation](https://github.com/Gentleman-Programming/gentle-ai) specifies test-first when a relevant runnable test exists; otherwise, explain the exception and verify another way. RDD defaults to on with opt-out, respects explicit disabling, and binds review to a frozen candidate. Automatic review is reserved for high-risk candidates; capabilities differ by integration. This does not authorize commit, push or release. A tidy workflow does not turn a superficial check into evidence.\n\n## Engram: remember decisions instead of recording everything\n\n[Engram](https://github.com/Gentleman-Programming/engram) is a local memory system for agents, built as a Go binary with SQLite and full-text search. It exposes a CLI, MCP server, HTTP API and TUI. An agent can save and search observations about decisions, discoveries, fixed bugs and project conventions. The documentation describes **curated memory**, not an indiscriminate log of every conversation.\n\nSuppose a portal treats long CRM IDs as strings to avoid precision loss in JavaScript. After a session, saving “CRM IDs remain strings in the API, sorting and exports; inspect the adapter before normalizing them” is more useful than retaining a hundred messages where the subject appeared. The next session can retrieve the decision, check that it still matches the code and proceed.\n\nThat last check is essential. A memory is a clue with provenance, not a higher-priority instruction or the repository's source of truth. If the contract changes, update or replace the observation. Engram keeps local SQLite authoritative: Git Sync exports portable chunks, while optional Engram Cloud provides project-scoped replication and shared access. Sharing memory also means deciding who can write, what may be stored and how conflicting decisions are resolved.\n\n## A sweet spot for a multi-agent environment\n\nWhen a coordinator delegates to different models, each worker should receive only the context it needs: goal, boundaries, repository state and relevant decisions. Engram can help retrieve those decisions; Gentle AI can provide repeatable configuration and workflow. Coordination and permission to change things still belong to the system directing the work and the people accountable for it.\n\nA practical pilot would be:\n\n1. Pick **one repository** with decisions that regularly need explaining again.\n2. Save a few useful observations: contracts, conventions, difficult bugs and architectural reasons. Link them to current code or documentation.\n3. Have the agent search at the start and **verify every retrieved memory** before using it.\n4. Across several tasks, measure repeated explanations avoided, relevant memories retrieved and stale ones found.\n5. Add workflow or review components only where the frequency and risk of changes warrant them.\n\nThe number of saved memories is a poor success measure. The useful signal is whether the next person or agent makes a sound decision with less reconstruction and visible evidence.\n\n## The limit that determines whether it helps\n\nPersistent memory has its own debt: obsolete information that sounds persuasive. Process can become bureaucracy when applied without regard to scale. Keep **memory**, **current state**, **proof** and **permission** separate. An observation alone does not authorize a production write; a checklist does not prove the right command ran.\n\nGentle AI and Engram are worth examining when the real pain is repeatedly explaining context, losing decisions between tools or struggling to resume delegated work. Testing them separately with simple measures can give the environment continuity without turning every task into a ceremony.\n", "language": "en" }, { "slug": "tailscale-red-privada-identidad", "title": "Tailscale: a private network built around identity", "summary": "Tailnets, WireGuard, direct connections, and relays: what Tailscale solves and what remains your responsibility.", "type": "concept", "order": 14, "tags": [ "tailscale", "networking", "wireguard", "identity", "infrastructure" ], "related": [ "tailscale-permisos-grants", "tailscale-entorno-agentes", "acceso-portatil-orca" ], "area": "Gobierno de agentes", "glyph": "◈", "hue": "rgba(87,217,232,.24)", "file": "tailscale-red-privada-identidad.md", "html": "A workstation running WSL, a travel laptop, and a VPS may hold everything needed to work together, yet still be difficult to connect. Addresses change, NAT gets in the way, and exposing SSH or an admin panel to the public internet creates another surface to maintain.
\nTailscale connects users and devices in a tailnet, a private overlay network. Each device joins with an authenticated identity, gets a stable address inside that network, and can be reached by name with MagicDNS. Joining a tailnet does not automatically secure every service: you still decide who can connect and what they may reach. What is a tailnet? · MagicDNS
\nWireGuard encrypts traffic between devices. The control plane coordinates identities, keys, and policies; the data plane carries encrypted packets. Tailscale tries a direct UDP connection. If the network prevents that, it can use a peer relay inside the tailnet or a DERP relay. Traffic remains end-to-end encrypted in all three cases; latency and throughput are the usual differences. Control and data planes · Connection types
\nA relay does not make a private service public. Nor should an architecture promise a direct connection regardless of NAT, firewalls, and the networks at both ends.
\n| Piece | \nQuestion | \nExample | \n
|---|---|---|
| Tailnet | \nWhich identities and devices belong? | \nLaptop, workstation, VPS | \n
| MagicDNS | \nHow do I find a node by a stable name? | \nworkstation instead of a changing IP | \n
| Grant | \nWho may reach which destination and port? | \nLaptop → workstation on TCP 22 | \n
| Service | \nWho may use the application after connecting? | \nLogin and permissions inside a dashboard | \n
A network grant permits a connection; it does not implement application authorization by itself. A MagicDNS name helps locate a device; it does not grant access.
\nYou can SSH from a laptop into the environment that already holds your repos and agents. A VPS can accept administrative connections within the tailnet without exposing that port publicly. A development dashboard can be shared with a small team using Tailscale Serve, subject to tailnet access controls. Serve
\nTailscale cannot turn on a powered-off workstation, restart a broken process, or replace backups. If Orca lives on a workstation, remote access depends on that workstation and WSL being available. Portable access to Orca describes this topology.
\nChoose one client, one host, and one service. Join both devices to the tailnet; check the name and connection; restrict access to the port you need. Add other destinations afterward. The next entry turns this into policies, grants, and negative tests: Permissions you can explain.
\n", "headings": [ { "label": "The problem with scattered machines", "depth": 2, "id": "the-problem-with-scattered-machines" }, { "label": "What happens when two nodes communicate", "depth": 2, "id": "what-happens-when-two-nodes-communicate" }, { "label": "Four pieces worth keeping separate", "depth": 2, "id": "four-pieces-worth-keeping-separate" }, { "label": "Where it changes daily work", "depth": 2, "id": "where-it-changes-daily-work" }, { "label": "A sensible first decision", "depth": 2, "id": "a-sensible-first-decision" } ], "raw": "---\nslug: tailscale-red-privada-identidad\ntitle: \"Tailscale: a private network built around identity\"\ntype: concept\norder: 14\nsummary: \"Tailnets, WireGuard, direct connections, and relays: what Tailscale solves and what remains your responsibility.\"\ntags: [tailscale, networking, wireguard, identity, infrastructure]\nrelated: [tailscale-permisos-grants, tailscale-entorno-agentes, acceso-portatil-orca]\narea: Gobierno de agentes\nglyph: ◈\nhue: rgba(87,217,232,.24)\n---\n\n# Tailscale: a private network built around identity\n\n## The problem with scattered machines\n\nA workstation running WSL, a travel laptop, and a VPS may hold everything needed to work together, yet still be difficult to connect. Addresses change, NAT gets in the way, and exposing SSH or an admin panel to the public internet creates another surface to maintain.\n\nTailscale connects users and devices in a **tailnet**, a private overlay network. Each device joins with an authenticated identity, gets a stable address inside that network, and can be reached by name with MagicDNS. Joining a tailnet does not automatically secure every service: you still decide who can connect and what they may reach. [What is a tailnet?](https://tailscale.com/docs/concepts/tailnet) · [MagicDNS](https://tailscale.com/docs/features/magicdns)\n\n## What happens when two nodes communicate\n\nWireGuard encrypts traffic between devices. The control plane coordinates identities, keys, and policies; the data plane carries encrypted packets. Tailscale tries a direct UDP connection. If the network prevents that, it can use a peer relay inside the tailnet or a DERP relay. Traffic remains end-to-end encrypted in all three cases; latency and throughput are the usual differences. [Control and data planes](https://tailscale.com/docs/concepts/control-data-planes) · [Connection types](https://tailscale.com/docs/reference/connection-types)\n\nA relay does not make a private service public. Nor should an architecture promise a direct connection regardless of NAT, firewalls, and the networks at both ends.\n\n## Four pieces worth keeping separate\n\n| Piece | Question | Example |\n| --- | --- | --- |\n| Tailnet | Which identities and devices belong? | Laptop, workstation, VPS |\n| MagicDNS | How do I find a node by a stable name? | `workstation` instead of a changing IP |\n| Grant | Who may reach which destination and port? | Laptop → workstation on TCP 22 |\n| Service | Who may use the application after connecting? | Login and permissions inside a dashboard |\n\nA network grant permits a connection; it does not implement application authorization by itself. A MagicDNS name helps locate a device; it does not grant access.\n\n## Where it changes daily work\n\nYou can SSH from a laptop into the environment that already holds your repos and agents. A VPS can accept administrative connections within the tailnet without exposing that port publicly. A development dashboard can be shared with a small team using Tailscale Serve, subject to tailnet access controls. [Serve](https://tailscale.com/docs/features/tailscale-serve)\n\nTailscale cannot turn on a powered-off workstation, restart a broken process, or replace backups. If Orca lives on a workstation, remote access depends on that workstation and WSL being available. [Portable access to Orca](/entrada/acceso-portatil-orca) describes this topology.\n\n## A sensible first decision\n\nChoose **one client, one host, and one service**. Join both devices to the tailnet; check the name and connection; restrict access to the port you need. Add other destinations afterward. The next entry turns this into policies, grants, and negative tests: [Permissions you can explain](/entrada/tailscale-permisos-grants).\n", "language": "en" }, { "slug": "tailscale-permisos-grants", "title": "Tailscale: permissions you can explain", "summary": "Design grants by identity, destination, and port; test allowed and denied access; separate networking, SSH, and application permissions.", "type": "guide", "order": 15, "tags": [ "tailscale", "grants", "acl", "ssh", "security", "policy" ], "related": [ "tailscale-red-privada-identidad", "tailscale-entorno-agentes", "acceso-portatil-orca" ], "area": "Gobierno de agentes", "glyph": "⚿", "hue": "rgba(168,106,255,.24)", "file": "tailscale-permisos-grants.md", "html": "The first prototype connects two devices and celebrates that they can see each other. An environment with agents, VPS instances, and internal dashboards needs a more precise question: which identity may initiate a connection to which destination on which port?
\nTailscale recommends grants for these permissions. Each grant defines src, dst, and network (ip) or application (app) capabilities. Connections without an allowing rule are denied. There is a catch: a new tailnet commonly starts with an allow all policy. Review and replace that broad rule before assuming least privilege. Grants · Default ACL policy
Consider a laptop, a development host, and a VPS. The goal is laptop → host for SSH, host → VPS for HTTPS, and no laptop access to the VPS database.
\n| Source | \nDestination | \nPort | \nDecision | \n
|---|---|---|---|
| Work laptop | \nDevelopment host | \nTCP 22 | \nAllow | \n
| Development host | \nInternal API on VPS | \nTCP 443 | \nAllow | \n
| Work laptop | \nDatabase on VPS | \nTCP 5432 | \nDeny | \n
One schematic implementation using grants is:
\n{\n \"tagOwners\": {\n \"tag:dev-host\": [\"autogroup:admin\"],\n \"tag:internal-api\": [\"autogroup:admin\"]\n },\n \"grants\": [\n {\n \"src\": [\"person@example.com\"],\n \"dst\": [\"tag:dev-host\"],\n \"ip\": [\"tcp:22\"]\n },\n {\n \"src\": [\"tag:dev-host\"],\n \"dst\": [\"tag:internal-api\"],\n \"ip\": [\"tcp:443\"]\n }\n ]\n}Adapt this example: the identity and names are fictitious, and the devices must actually be assigned those tags. Review existing grants and ACLs before applying a real policy. A broad existing rule can still allow traffic: policies add permissions; they do not offer a deny rule to subtract access granted elsewhere. Grant syntax · Tags
An email src identifies the user, not just their laptop: it can also allow their other user-owned devices. To restrict this to one machine, use a device selector, such as its Tailscale IP or a hosts alias, and verify the scope in the preview. Grant selectors
Regular SSH over Tailscale keeps the host's sshd, local users, and SSH keys; the tailnet provides a private route, while the grant permits the port. Tailscale SSH lets Tailscale manage SSH authentication and authorization on supported nodes, with separate ssh policy rules and options such as check. Opening TCP 22 with a grant does not configure Tailscale SSH. Tailscale SSH also cannot connect to a machine that only sits behind a subnet router. Tailscale SSH
If the existing Orca SSH workflow works, keeping it while restricting the network route is a reasonable first step. Migrating to Tailscale SSH deserves its own test of users, sessions, and recovery.
\nStart with Preview rules to inspect a user's reachable destinations and add policy tests for expected connections. Then test from a real device: SSH into the allowed host, and attempt the restricted port on a destination that is online and listening. A timeout to an offline machine proves nothing about the policy. Editing and previewing policies
\nFor diagnosis, tailscale ping --tsmp tests connectivity before access controls; tailscale ping --icmp includes access controls. If both work but the application fails, check the port, service, and its own permissions. Use the actual protocol to test a particular port: ping cannot prove that TCP 22 or 443 is permitted.
The result should fit in one sentence: “this identity can reach this service on this port, and cannot reach that one.” The agent environment case shows where to place those connections.
\n", "headings": [ { "label": "Membership is not a permission model", "depth": 2, "id": "membership-is-not-a-permission-model" }, { "label": "Draw the policy before editing it", "depth": 2, "id": "draw-the-policy-before-editing-it" }, { "label": "SSH has two operating modes", "depth": 2, "id": "ssh-has-two-operating-modes" }, { "label": "Test that the boundary exists", "depth": 2, "id": "test-that-the-boundary-exists" } ], "raw": "---\nslug: tailscale-permisos-grants\ntitle: \"Tailscale: permissions you can explain\"\ntype: guide\norder: 15\nsummary: \"Design grants by identity, destination, and port; test allowed and denied access; separate networking, SSH, and application permissions.\"\ntags: [tailscale, grants, acl, ssh, security, policy]\nrelated: [tailscale-red-privada-identidad, tailscale-entorno-agentes, acceso-portatil-orca]\narea: Gobierno de agentes\nglyph: ⚿\nhue: rgba(168,106,255,.24)\n---\n\n# Tailscale: permissions you can explain\n\n## Membership is not a permission model\n\nThe first prototype connects two devices and celebrates that they can see each other. An environment with agents, VPS instances, and internal dashboards needs a more precise question: **which identity may initiate a connection to which destination on which port?**\n\nTailscale recommends **grants** for these permissions. Each grant defines `src`, `dst`, and network (`ip`) or application (`app`) capabilities. Connections without an allowing rule are denied. There is a catch: a new tailnet commonly starts with an *allow all* policy. Review and replace that broad rule before assuming least privilege. [Grants](https://tailscale.com/docs/features/access-control/grants) · [Default ACL policy](https://tailscale.com/docs/features/access-control/acls)\n\n## Draw the policy before editing it\n\nConsider a laptop, a development host, and a VPS. The goal is laptop → host for SSH, host → VPS for HTTPS, and no laptop access to the VPS database.\n\n| Source | Destination | Port | Decision |\n| --- | --- | --- | --- |\n| Work laptop | Development host | TCP 22 | Allow |\n| Development host | Internal API on VPS | TCP 443 | Allow |\n| Work laptop | Database on VPS | TCP 5432 | Deny |\n\nOne schematic implementation using grants is:\n\n```json\n{\n \"tagOwners\": {\n \"tag:dev-host\": [\"autogroup:admin\"],\n \"tag:internal-api\": [\"autogroup:admin\"]\n },\n \"grants\": [\n {\n \"src\": [\"person@example.com\"],\n \"dst\": [\"tag:dev-host\"],\n \"ip\": [\"tcp:22\"]\n },\n {\n \"src\": [\"tag:dev-host\"],\n \"dst\": [\"tag:internal-api\"],\n \"ip\": [\"tcp:443\"]\n }\n ]\n}\n```\n\nAdapt this example: the identity and names are fictitious, and the devices must actually be assigned those tags. Review existing grants and ACLs before applying a real policy. A broad existing rule can still allow traffic: policies add permissions; they do not offer a `deny` rule to subtract access granted elsewhere. [Grant syntax](https://tailscale.com/docs/reference/syntax/grants) · [Tags](https://tailscale.com/docs/features/tags)\n\nAn email `src` identifies the user, not just their laptop: it can also allow their other user-owned devices. To restrict this to one machine, use a device selector, such as its Tailscale IP or a `hosts` alias, and verify the scope in the preview. [Grant selectors](https://tailscale.com/docs/reference/syntax/grants)\n\n## SSH has two operating modes\n\n**Regular SSH over Tailscale** keeps the host's `sshd`, local users, and SSH keys; the tailnet provides a private route, while the grant permits the port. **Tailscale SSH** lets Tailscale manage SSH authentication and authorization on supported nodes, with separate `ssh` policy rules and options such as `check`. Opening TCP 22 with a grant does not configure Tailscale SSH. Tailscale SSH also cannot connect to a machine that only sits behind a subnet router. [Tailscale SSH](https://tailscale.com/docs/features/tailscale-ssh)\n\nIf the existing Orca SSH workflow works, keeping it while restricting the network route is a reasonable first step. Migrating to Tailscale SSH deserves its own test of users, sessions, and recovery.\n\n## Test that the boundary exists\n\nStart with **Preview rules** to inspect a user's reachable destinations and add policy tests for expected connections. Then test from a real device: SSH into the allowed host, and attempt the restricted port on a destination that is **online and listening**. A timeout to an offline machine proves nothing about the policy. [Editing and previewing policies](https://tailscale.com/docs/features/tailnet-policy-file/manage-tailnet-policies)\n\nFor diagnosis, `tailscale ping --tsmp` tests connectivity before access controls; `tailscale ping --icmp` includes access controls. If both work but the application fails, check the port, service, and its own permissions. Use the actual protocol to test a particular port: ping cannot prove that TCP 22 or 443 is permitted.\n\nThe result should fit in one sentence: “this identity can reach this service on this port, and cannot reach that one.” The [agent environment case](/entrada/tailscale-entorno-agentes) shows where to place those connections.\n", "language": "en" }, { "slug": "comparar-harness-cli-codex-claude-opencode-cline", "title": "Comparing CLI harnesses: Codex, Claude Code, OpenCode V2, Cline and OMP", "summary": "The strengths, differences and drawbacks of five coding harnesses: how to choose them, assign responsibilities and assess the real cost of agent work.", "type": "editorial", "order": 18, "tags": [ "harness", "cli", "codex", "claude-code", "opencode", "cline", "omp", "agents", "permissions" ], "related": [ "guia-escalado-modelos", "terminal-vs-web-superficies-trabajo", "orquestacion", "enrutamiento-modelo-esfuerzo-rol-harness" ], "area": "Gobierno de agentes", "glyph": "⚿", "hue": "rgba(168,106,255,.24)", "file": "comparar-harness-cli-codex-claude-opencode-cline.md", "html": "\n\nUpdated on October 12, 2026. Capabilities depend on the installed version and configuration.
\n
Choosing a coding agent often begins with a question: which model should I use? Another decision shapes everyday work: which harness will turn that model's responses into actions on a project?
\nCodex CLI, Claude Code, OpenCode, Cline and Oh My Pi (OMP) can fill that role. They share the goal of working with code and tools, but organize context, permissions, extensions and execution differently. Understanding those differences helps you choose deliberately and combine tools without turning the repository into four agents competing for the same file.
\nThis comparison separates documented capabilities from editorial recommendations. The suggested roles are a proposed operating model, rather than a benchmark of quality, speed or cost.
\nThe model interprets information and proposes actions. The harness manages the working loop: it prepares context, exposes tools, executes calls, collects results and allows work to continue until there is a deliverable or a blocker.
\nThe CLI is the terminal interface to that system. Harness and CLI are related but distinct: the same agent can have a terminal interface, an editor extension and a desktop application.
\nChanging interfaces therefore does not always mean changing agents. Using a similar model in two tools can also produce different experiences. Instructions, available tools and session management all matter.
\nFive questions help guide the choice: which models are available, how execution is controlled, how context carries forward, how the tool integrates with the project and how much the whole system costs to operate.
\nCodex CLI can inspect a repository, edit files and run local tools. It supports interactive work and automation through codex exec, along with model, reasoning effort and permission selection. Official documentation.
Its sandbox sets boundaries for executed commands, with platform-specific enforcement. Approval policy determines when an action requires authorization; that is a separate layer from the sandbox. Codex sandbox.
\nEditorial advantage: it is an attractive candidate when you want to delegate implementation and review a concrete delivery: changes, executed commands and validation. Execution boundaries help define what the agent can do during that work.
\nPractical drawback: an unprepared environment can block installations, network access or tools the project requires. Resolving that requires configuring permissions and dependencies. Automatically granting full access removes part of the control that motivated the choice.
\nCodex also supports custom providers with a Responses API-compatible endpoint and local providers through --oss. Chat Completions support alone is insufficient: validate protocol, tools and authentication. Provider configuration.
Suggested role: bounded implementation, error diagnosis and change review that can be checked with the repository's actual tools.
\nClaude Code provides project context through CLAUDE.md, skills, MCP, hooks and plugins. Hooks associate actions with execution lifecycle events. Claude Code extensions.
Its subagents can have their own instructions, tools and permissions, as well as separate context. Their requests count toward the applicable usage limits; delegation does not make work free. Claude Code subagents.
\nEditorial advantage: these components help turn a recurring workflow into reusable configuration. Exploration, implementation and review can have clear responsibilities.
\nPractical drawback: each specialization adds maintenance. Repeated instructions, unnecessary hooks and overly broad delegation can increase consumption and make the agent's behavior harder to explain.
\nThe product is centered on the Claude ecosystem. That simplifies some decisions, but matters if you want execution infrastructure that alternates between independent providers.
\nSuggested role: a candidate for coordinating tasks that require splitting responsibilities and preserving project conventions. That role is an architectural choice, rather than a claim of superiority over Codex.
\nOpenCode's official site references V2 in its installation instructions and presents an open tool available in terminal, editor and desktop, with multiple providers and local models. OpenCode. This editorial covers the current offering; it does not assign improvements to V2 without comparing releases.
\nOpenCode documents primary agents, subagents and per-agent model configuration. Build and Plan have different tool access. Agents. Permissions can allow, request approval for or deny actions; the documentation describes mostly permissive defaults. Permissions.
\nEditorial advantage: you can assign models by task. A provider can handle exploration and another implementation without necessarily replacing the working interface.
\nPractical drawback: that freedom transfers decisions to the operator. Models, tool compatibility, provider limits and error behavior need evaluation. Two models appearing in the same selector does not mean they complete a task with equal reliability.
\nV2 has its own documentation and schema: permissions, shell and subagent replace V1 names. “Allow always” saves project-scoped approvals; subagents use their own permissions. Review these scopes before migration. V2 permissions.
Permission configuration deserves its own attention. A harness rule and an operating-system boundary are different mechanisms and should not be treated as equivalent.
\nSuggested role: specialized executors and controlled provider experiments. To reduce costs, measure accepted tasks and subsequent corrections rather than token price alone.
\nCline has an interactive CLI and headless mode. Its documentation covers pipes, JSON output, provider selection through authentication and MCP management. It also supports unattended execution through auto-approval, which can modify files and run commands. Cline CLI.
\nEditorial advantage: it is a practical candidate for focused assignments with a concrete input and result: analyzing a diff, explaining a failure or preparing a review. Its CLI can integrate those tasks into scripts.
\nPractical drawback: a seemingly small assignment can grow without boundaries. A review request can turn into implementation if its objective and permissions remain open. Changing providers also calls for reassessing output quality.
\nCline’s current reference lists --auto-approve as defaulting to true and has no native shell-command allow/deny list, pointing to PreToolUse hooks instead. Do not assume confirmation will occur or that a review assignment will be read-only. CLI controls.
Headless describes execution without an interactive interface; it does not establish isolation or reliability by itself. Automation requires deciding which changes are authorized and how output will be accepted.
\nSuggested role: a flexible tool for bounded tasks and a second look at changes prepared by another agent. It can also handle primary work when that better suits the project; the supporting role is an operational choice.
\nOMP is a coding-oriented fork of Pi. It combines support for multiple providers with built-in search, LSP, debugging, execution and hash-anchored editing tools. It also supports extensions and subagents. OMP project.
\nEditorial advantage: a compelling candidate for experimenting with the same model family across different tool surfaces. Its specialized tools may be especially useful for symbolic navigation, localized refactors and code inspection.
\nPractical drawback: additional tools do not guarantee better outcomes. LSP availability depends on the environment and language, extensions require maintenance, and its permissions should not automatically be equated with Codex's sandbox.
\nSuggested role: structural exploration, narrowly scoped changes and A/B testing against another harness using the same model. Benchmarks published by its maintainers must be verified on your own codebase; they are not an independent Codex comparison.
\nThis table summarizes the editorial recommendations above.
\n| Harness | \nAdvantage to use | \nDrawback to manage | \nSuggested role | \n
|---|---|---|---|
| Codex CLI | \nLocal work with configurable execution boundaries | \nFriction when permissions or environment do not fit the project | \nBounded implementation and validation | \n
| Claude Code | \nSpecialization through context, extensions and subagents | \nConsumption and configuration maintenance | \nResponsibility coordination | \n
| OpenCode V2 | \nFlexibility to combine providers and agents | \nOperator-owned evaluation and configuration | \nSpecialized executors | \n
| Cline CLI | \nInteractive assignments or script integration | \nScope control and output acceptance | \nFlexible support and additional review | \n
| OMP | \nLSP, specialized editing tools and multi-provider extensibility | \nConfiguration burden and verification of execution controls | \nStructural exploration and cross-harness experiments | \n
These roles overlap. The extended model of choosing a harness per responsibility is covered in Advanced routing: model, effort, role and harness. The table suggests where to begin testing each tool, rather than exclusive assignments.
\nA reasonable combination starts with one task owner. That agent or person preserves the objective, decides what to delegate and accepts the result. Each executor receives an assignment with a verifiable completion condition.
\nFor example, to fix an integration:
\nThe work can be distributed across these five harnesses without using all of them. Two tools with clear responsibilities can contribute more than five open sessions with duplicated context.
\nDelegation across products requires explicit integration: a command, script, API or another available mechanism. A native subagent in one harness does not automatically become a session in another.
\nEach assignment should define the objective, authorized files, constraints, validation and expected output. That contract makes it possible to switch tools without reconstructing the whole intent of the work.
\nChoose representative tasks: a reproducible bug, a small modification and a code review. Prepare the same starting point and record the model, version, permissions and context for each trial.
\nCompare time to an acceptable result, human interventions, cost or quota consumption and defects found later. When model and harness change simultaneously, treat the result as an evaluation of the complete combination.
\nThe useful question is how much reliable work you get for the total cost. That includes reviewing, correcting, maintaining configuration and recovering context, alongside inference charges.
\nCodex, Claude Code, OpenCode, Cline and OMP offer different entry points to the same problem: turning an intention into executable, reviewable work.
\nThe choice improves when the project keeps its contracts, conventions and checks outside any particular session. The harness can then change while the team still knows what needed doing, what was done and how it was verified.
\nThe autonomy worth expanding is the kind that produces enough evidence to trust the delivery.
\n", "headings": [ { "label": "What a harness does and how the CLI fits", "depth": 2, "id": "what-a-harness-does-and-how-the-cli-fits" }, { "label": "Codex CLI and work within explicit boundaries", "depth": 2, "id": "codex-cli-and-work-within-explicit-boundaries" }, { "label": "Claude Code and workflow specialization", "depth": 2, "id": "claude-code-and-workflow-specialization" }, { "label": "OpenCode V2 and provider flexibility", "depth": 2, "id": "opencode-v2-and-provider-flexibility" }, { "label": "Cline and tasks that enter and leave through the terminal", "depth": 2, "id": "cline-and-tasks-that-enter-and-leave-through-the-terminal" }, { "label": "Oh My Pi (OMP) and harness instrumentation", "depth": 2, "id": "oh-my-pi-omp-and-harness-instrumentation" }, { "label": "Comparing strengths and operating costs", "depth": 2, "id": "comparing-strengths-and-operating-costs" }, { "label": "Combining tools without multiplying disorder", "depth": 2, "id": "combining-tools-without-multiplying-disorder" }, { "label": "Evaluating the fit for your project", "depth": 2, "id": "evaluating-the-fit-for-your-project" }, { "label": "Choose according to the responsibility you delegate", "depth": 2, "id": "choose-according-to-the-responsibility-you-delegate" } ], "raw": "---\nslug: comparar-harness-cli-codex-claude-opencode-cline\ntitle: \"Comparing CLI harnesses: Codex, Claude Code, OpenCode V2, Cline and OMP\"\ntype: editorial\norder: 18\nsummary: \"The strengths, differences and drawbacks of five coding harnesses: how to choose them, assign responsibilities and assess the real cost of agent work.\"\ntags: [harness, cli, codex, claude-code, opencode, cline, omp, agents, permissions]\nrelated: [guia-escalado-modelos, terminal-vs-web-superficies-trabajo, orquestacion, enrutamiento-modelo-esfuerzo-rol-harness]\narea: Gobierno de agentes\nglyph: ⚿\nhue: rgba(168,106,255,.24)\n---\n\n# Comparing CLI harnesses: Codex, Claude Code, OpenCode V2, Cline and OMP\n\n> Updated on October 12, 2026. Capabilities depend on the installed version and configuration.\n\nChoosing a coding agent often begins with a question: which model should I use? Another decision shapes everyday work: which harness will turn that model's responses into actions on a project?\n\nCodex CLI, Claude Code, OpenCode, Cline and Oh My Pi (OMP) can fill that role. They share the goal of working with code and tools, but organize context, permissions, extensions and execution differently. Understanding those differences helps you choose deliberately and combine tools without turning the repository into four agents competing for the same file.\n\nThis comparison separates documented capabilities from editorial recommendations. The suggested roles are a proposed operating model, rather than a benchmark of quality, speed or cost.\n\n## What a harness does and how the CLI fits\n\nThe model interprets information and proposes actions. The harness manages the working loop: it prepares context, exposes tools, executes calls, collects results and allows work to continue until there is a deliverable or a blocker.\n\nThe CLI is the terminal interface to that system. Harness and CLI are related but distinct: the same agent can have a terminal interface, an editor extension and a desktop application.\n\nChanging interfaces therefore does not always mean changing agents. Using a similar model in two tools can also produce different experiences. Instructions, available tools and session management all matter.\n\nFive questions help guide the choice: which models are available, how execution is controlled, how context carries forward, how the tool integrates with the project and how much the whole system costs to operate.\n\n## Codex CLI and work within explicit boundaries\n\nCodex CLI can inspect a repository, edit files and run local tools. It supports interactive work and automation through `codex exec`, along with model, reasoning effort and permission selection. [Official documentation](https://learn.chatgpt.com/docs/codex/cli).\n\nIts sandbox sets boundaries for executed commands, with platform-specific enforcement. Approval policy determines when an action requires authorization; that is a separate layer from the sandbox. [Codex sandbox](https://learn.chatgpt.com/docs/sandboxing).\n\n**Editorial advantage:** it is an attractive candidate when you want to delegate implementation and review a concrete delivery: changes, executed commands and validation. Execution boundaries help define what the agent can do during that work.\n\n**Practical drawback:** an unprepared environment can block installations, network access or tools the project requires. Resolving that requires configuring permissions and dependencies. Automatically granting full access removes part of the control that motivated the choice.\n\nCodex also supports custom providers with a Responses API-compatible endpoint and local providers through `--oss`. Chat Completions support alone is insufficient: validate protocol, tools and authentication. [Provider configuration](https://learn.chatgpt.com/docs/config-file/config-advanced).\n\n**Suggested role:** bounded implementation, error diagnosis and change review that can be checked with the repository's actual tools.\n\n## Claude Code and workflow specialization\n\nClaude Code provides project context through `CLAUDE.md`, skills, MCP, hooks and plugins. Hooks associate actions with execution lifecycle events. [Claude Code extensions](https://code.claude.com/docs/en/features-overview).\n\nIts subagents can have their own instructions, tools and permissions, as well as separate context. Their requests count toward the applicable usage limits; delegation does not make work free. [Claude Code subagents](https://code.claude.com/docs/en/sub-agents).\n\n**Editorial advantage:** these components help turn a recurring workflow into reusable configuration. Exploration, implementation and review can have clear responsibilities.\n\n**Practical drawback:** each specialization adds maintenance. Repeated instructions, unnecessary hooks and overly broad delegation can increase consumption and make the agent's behavior harder to explain.\n\nThe product is centered on the Claude ecosystem. That simplifies some decisions, but matters if you want execution infrastructure that alternates between independent providers.\n\n**Suggested role:** a candidate for coordinating tasks that require splitting responsibilities and preserving project conventions. That role is an architectural choice, rather than a claim of superiority over Codex.\n\n## OpenCode V2 and provider flexibility\n\nOpenCode's official site references V2 in its installation instructions and presents an open tool available in terminal, editor and desktop, with multiple providers and local models. [OpenCode](https://opencode.ai/). This editorial covers the current offering; it does not assign improvements to V2 without comparing releases.\n\nOpenCode documents primary agents, subagents and per-agent model configuration. Build and Plan have different tool access. [Agents](https://opencode.ai/v2/docs/agents/). Permissions can allow, request approval for or deny actions; the documentation describes mostly permissive defaults. [Permissions](https://opencode.ai/v2/docs/permissions/).\n\n**Editorial advantage:** you can assign models by task. A provider can handle exploration and another implementation without necessarily replacing the working interface.\n\n**Practical drawback:** that freedom transfers decisions to the operator. Models, tool compatibility, provider limits and error behavior need evaluation. Two models appearing in the same selector does not mean they complete a task with equal reliability.\n\nV2 has its own documentation and schema: `permissions`, `shell` and `subagent` replace V1 names. “Allow always” saves project-scoped approvals; subagents use their own permissions. Review these scopes before migration. [V2 permissions](https://opencode.ai/v2/docs/permissions/).\n\nPermission configuration deserves its own attention. A harness rule and an operating-system boundary are different mechanisms and should not be treated as equivalent.\n\n**Suggested role:** specialized executors and controlled provider experiments. To reduce costs, measure accepted tasks and subsequent corrections rather than token price alone.\n\n## Cline and tasks that enter and leave through the terminal\n\nCline has an interactive CLI and headless mode. Its documentation covers pipes, JSON output, provider selection through authentication and MCP management. It also supports unattended execution through auto-approval, which can modify files and run commands. [Cline CLI](https://docs.cline.bot/usage/cli-overview).\n\n**Editorial advantage:** it is a practical candidate for focused assignments with a concrete input and result: analyzing a diff, explaining a failure or preparing a review. Its CLI can integrate those tasks into scripts.\n\n**Practical drawback:** a seemingly small assignment can grow without boundaries. A review request can turn into implementation if its objective and permissions remain open. Changing providers also calls for reassessing output quality.\n\nCline’s current reference lists `--auto-approve` as defaulting to `true` and has no native shell-command allow/deny list, pointing to `PreToolUse` hooks instead. Do not assume confirmation will occur or that a review assignment will be read-only. [CLI controls](https://docs.cline.bot/usage/cli-overview).\n\nHeadless describes execution without an interactive interface; it does not establish isolation or reliability by itself. Automation requires deciding which changes are authorized and how output will be accepted.\n\n**Suggested role:** a flexible tool for bounded tasks and a second look at changes prepared by another agent. It can also handle primary work when that better suits the project; the supporting role is an operational choice.\n\n## Oh My Pi (OMP) and harness instrumentation\n\nOMP is a coding-oriented fork of Pi. It combines support for multiple providers with built-in search, LSP, debugging, execution and hash-anchored editing tools. It also supports extensions and subagents. [OMP project](https://github.com/can1357/oh-my-pi).\n\n**Editorial advantage:** a compelling candidate for experimenting with the same model family across different tool surfaces. Its specialized tools may be especially useful for symbolic navigation, localized refactors and code inspection.\n\n**Practical drawback:** additional tools do not guarantee better outcomes. LSP availability depends on the environment and language, extensions require maintenance, and its permissions should not automatically be equated with Codex's sandbox.\n\n**Suggested role:** structural exploration, narrowly scoped changes and A/B testing against another harness using the same model. Benchmarks published by its maintainers must be verified on your own codebase; they are not an independent Codex comparison.\n\n## Comparing strengths and operating costs\n\nThis table summarizes the editorial recommendations above.\n\n| Harness | Advantage to use | Drawback to manage | Suggested role |\n| --- | --- | --- | --- |\n| Codex CLI | Local work with configurable execution boundaries | Friction when permissions or environment do not fit the project | Bounded implementation and validation |\n| Claude Code | Specialization through context, extensions and subagents | Consumption and configuration maintenance | Responsibility coordination |\n| OpenCode V2 | Flexibility to combine providers and agents | Operator-owned evaluation and configuration | Specialized executors |\n| Cline CLI | Interactive assignments or script integration | Scope control and output acceptance | Flexible support and additional review |\n| OMP | LSP, specialized editing tools and multi-provider extensibility | Configuration burden and verification of execution controls | Structural exploration and cross-harness experiments |\n\nThese roles overlap. The extended model of choosing a harness per responsibility is covered in [Advanced routing: model, effort, role and harness](/entrada/enrutamiento-modelo-esfuerzo-rol-harness). The table suggests where to begin testing each tool, rather than exclusive assignments.\n\n## Combining tools without multiplying disorder\n\nA reasonable combination starts with one task owner. That agent or person preserves the objective, decides what to delegate and accepts the result. Each executor receives an assignment with a verifiable completion condition.\n\nFor example, to fix an integration:\n\n1. The owner defines the expected contract and reproduces the error.\n2. An executor prepares the change in its own branch or worktree.\n3. Another agent reviews the diff with read access and looks for omitted cases.\n4. The owner checks actual execution, resolves findings and prepares delivery.\n\nThe work can be distributed across these five harnesses without using all of them. Two tools with clear responsibilities can contribute more than five open sessions with duplicated context.\n\nDelegation across products requires explicit integration: a command, script, API or another available mechanism. A native subagent in one harness does not automatically become a session in another.\n\nEach assignment should define the objective, authorized files, constraints, validation and expected output. That contract makes it possible to switch tools without reconstructing the whole intent of the work.\n\n## Evaluating the fit for your project\n\nChoose representative tasks: a reproducible bug, a small modification and a code review. Prepare the same starting point and record the model, version, permissions and context for each trial.\n\nCompare time to an acceptable result, human interventions, cost or quota consumption and defects found later. When model and harness change simultaneously, treat the result as an evaluation of the complete combination.\n\nThe useful question is how much reliable work you get for the total cost. That includes reviewing, correcting, maintaining configuration and recovering context, alongside inference charges.\n\n## Choose according to the responsibility you delegate\n\nCodex, Claude Code, OpenCode, Cline and OMP offer different entry points to the same problem: turning an intention into executable, reviewable work.\n\nThe choice improves when the project keeps its contracts, conventions and checks outside any particular session. The harness can then change while the team still knows what needed doing, what was done and how it was verified.\n\nThe autonomy worth expanding is the kind that produces enough evidence to trust the delivery.\n", "language": "en" }, { "slug": "enrutamiento-modelo-esfuerzo-rol-harness", "title": "Advanced agent routing: model, effort, role and harness", "summary": "Why agent selection must account for model, reasoning effort, task role and execution harness, using Codex versus OMP as a controlled contrast.", "type": "editorial", "order": 19, "tags": [ "orchestration", "harness", "cli", "codex", "omp", "routing", "agents", "benchmarks", "governance" ], "related": [ "comparar-harness-cli-codex-claude-opencode-cline", "guia-escalado-modelos", "orquestacion" ], "area": "Gobierno de agentes", "glyph": "⌘", "hue": "rgba(87,217,232,.24)", "file": "enrutamiento-modelo-esfuerzo-rol-harness.md", "html": "\n\nArchitecture proposal, October 8, 2026. This is not a claim of an already validated deployment. Documented features, hypotheses and results still requiring measurement are kept separate.
\n
Early orchestration strategies asked which model to use and how much reasoning effort to allocate. Roles add what function an agent should perform. A further decision remains: which harness should execute that task?
\nThe operational configuration becomes model + effort + role + harness, rather than only model plus effort. This is not a complete score function: permissions, codebase, budget, context and availability remain hard eligibility constraints.
Even with identical model weights, harness instructions, read outputs, editing tools and compaction strategies can change observed behavior. Model comparisons that ignore the execution surface can therefore confuse causes.
\nCodex CLI and Oh My Pi can run compatible OpenAI-family models, depending on version and authentication. This creates a useful experiment: same model, same effort, same task, different harness.
\nCodex has an integrated workflow for reading, editing, running commands, approvals and sandboxing. It is a reasonable initial candidate for complete implementations with tests and auditable delivery. Codex.
\nOMP, a Pi fork, includes specialized tools such as LSP integration, debugging and hash-anchored editing, along with multi-provider support and extensibility. It is an interesting candidate for references, symbol navigation and focused modifications. OMP.
\nNeither product is proven superior by this feature comparison. LSP can reduce exploration when supported by the language and environment, but add little to small or unindexed projects. Integrated workflows may improve consistency on longer assignments, but that too needs measurement. Maintainer-published benchmarks are not a substitute for tests on your own repository.
\n| Dimension | \nCodex CLI | \nOMP | \nQuestion to test | \n
|---|---|---|---|
| Execution | \nIntegrated tool and command loop | \nSpecialized, extensible tooling | \nWhich needs fewer human interventions? | \n
| Exploration | \nRepository reading and search | \nSearch and LSP when available | \nWhich locates correct changes with fewer reads? | \n
| Editing | \nAgent editing tools | \nHash-anchored and structured edits | \nWhich incurs fewer failed attempts? | \n
| Context | \nBuilt-in session and compaction | \nIts own configurable session strategies | \nWhich preserves task constraints? | \n
| Safety | \nSandbox and explicit approvals | \nControls depend on setup and tools | \nWhich enforces the same restrictions? | \n
| Cost | \nSubscription quota or API, depending on access | \nCompatible subscription or separate API, depending on provider | \nWhich lowers cost per accepted task? | \n
The harness and the inference provider are different choices. OMP authentication paths can change billing, model availability and limits. A Codex subscription and an OpenAI API key must not be assumed interchangeable. Record the effective model ID and authentication route before benchmarking. A harness alias is also insufficient: OpenCode V2, for example, separates its catalog ID from the modelID sent to the provider. Record both before claiming two runs used the same model. Aliases and providers.
A coordinator choosing only the strongest model may waste capacity while using unsuitable tools. A more precise scheduler:
\nRoles are contracts, not decorations. A read-only reviewer must not gain write access merely because routing selects another CLI. Determine authorized actions before selecting the harness.
\n| Assignment | \nRole | \nInitial candidate | \nWhen to prefer it | \n
|---|---|---|---|
| Locate cross-module impact | \nExplorer | \nOMP | \nWorking LSP and measured reduction in reads | \n
| Fix a reproducible bug | \nImplementer | \nCodex | \nHigher accepted-resolution rate | \n
| Symbol-level refactor | \nSpecialized implementer | \nOMP | \nVerified structural edits and renames | \n
| Cross-layer change | \nImplementer | \nCodex | \nBetter consistency across tests and contracts | \n
| Review a diff | \nReviewer | \nAny eligible read-only harness | \nFewer missed defects and lower review cost | \n
| Recover a failed run | \nDiagnostic fallback | \nAnother eligible harness | \nEvidence a tooling change helps | \n
These are routing hypotheses, not exclusive product capabilities. If empirical results disagree, update the matrix.
\nCross-harness delegation works best when the coordinator creates a provider-independent task envelope:
\ntask_id: BUG-142\nrole: implementer\ngoal: \"Fix duplicate events without changing the HTTP contract\"\nrepository_ref: \"immutable-commit\"\nscope:\n writable: [\"src/events/**\", \"tests/events/**\"]\nconstraints:\n network: false\n secrets: none\n production_write: false\nacceptance:\n - \"regression tests pass\"\n - \"diff stays in scope\"\noutputs: [\"summary\", \"diff\", \"tests\", \"usage\", \"blockers\"]This contract must be translated into actual harness and operating-system enforcement. Writing network: false in YAML does not disable the network. A harness unable to satisfy critical constraints must be ineligible, no matter its benchmark score.
October 12, 2026 update: the V4 operational case now documents general direction with Opus, integration with Sol low and package coordination with Sol medium. LIVE implementation and auditing are split across different families. This establishes a policy adopted in one project, not a validated automatic router or a measured performance advantage. This article's proposed A/B experiment still awaits that validation.
\nHarness verification also remains an eligibility condition. In the reviewed OMP 18.10.0 installation, role rules existed in configuration, but effective session loading and enforcement were not demonstrated; allowing LSP also left rename operations to be checked. A “read” label does not prove the absence of writes. Before assigning a read-only auditor, verify effective runtime behavior and negative actions, not just the configuration file.
\nFor the same reason, a quota notice does not automatically change model, effort or provider. Technical-failure recovery and human quota management are separate decisions; neither authorizes seeking a route with weaker controls.
\nFor paired tasks, hold constant the starting commit, fixtures, effective model version where possible, reasoning effort, functional instructions, scope, budget and acceptance checks. Record unavoidable differences in system prompts, tools and compaction, because these are part of the experimental treatment.
\nUse representative tasks and at least three runs per configuration, fresh worktrees and no reused solutions. Measure:
\nThe central outcome is total cost per accepted task, including review, rework and failures, not simply patch-generation time. Where usage accounting differs between providers, report it separately and favor observed monetary cost and independently checked outcomes.
\nAn advanced router must avoid two traps: switching harnesses automatically on every error, and rewarding whichever agent reports success fastest. A logic failure is not necessarily a harness failure, and success requires independent acceptance.
\nRecord (task type, model, effort, harness, version, tools, permissions, outcome) and update preferences only with meaningful samples. Infrastructure or tool failures can trigger compatible fallbacks. Safety violations must stop and escalate, not seek a more permissive harness.
Switching execution surfaces has costs too: setup, context reconstruction, logs and new failure modes. A consistent single-harness system can outperform a complex router at small scale.
\nThe point is not to accumulate CLIs, but to stop treating the harness as an invisible constant.
\nA mature coordinator should ask: Which model, effort, role and harness combination delivers a verifiable result for this task within its constraints and budget?
\nAnswer with portable contracts, reproducible experiments and accepted-task metrics, not brand loyalties. The harness becomes a planning variable rather than a terminal preference.
\nFor the broader product comparison, see Comparing CLI harnesses.
\n", "headings": [ { "label": "The fourth parameter", "depth": 2, "id": "the-fourth-parameter" }, { "label": "Controlled contrast: OpenAI in Codex and OMP", "depth": 2, "id": "controlled-contrast-openai-in-codex-and-omp" }, { "label": "Routing as a planning problem", "depth": 2, "id": "routing-as-a-planning-problem" }, { "label": "An initial routing matrix", "depth": 2, "id": "an-initial-routing-matrix" }, { "label": "A portable task contract", "depth": 2, "id": "a-portable-task-contract" }, { "label": "From proposed design to a contextual assignment", "depth": 2, "id": "from-proposed-design-to-a-contextual-assignment" }, { "label": "A/B benchmarking: isolate the harness effect", "depth": 2, "id": "a-b-benchmarking-isolate-the-harness-effect" }, { "label": "Fallback, learning and limits", "depth": 2, "id": "fallback-learning-and-limits" }, { "label": "From choosing the best model to choosing the best working environment", "depth": 2, "id": "from-choosing-the-best-model-to-choosing-the-best-working-environment" } ], "raw": "---\nslug: enrutamiento-modelo-esfuerzo-rol-harness\ntitle: \"Advanced agent routing: model, effort, role and harness\"\ntype: editorial\norder: 19\nsummary: \"Why agent selection must account for model, reasoning effort, task role and execution harness, using Codex versus OMP as a controlled contrast.\"\ntags: [orchestration, harness, cli, codex, omp, routing, agents, benchmarks, governance]\nrelated: [comparar-harness-cli-codex-claude-opencode-cline, guia-escalado-modelos, orquestacion]\narea: Gobierno de agentes\nglyph: ⌘\nhue: rgba(87,217,232,.24)\n---\n\n# Advanced agent routing: model, effort, role and harness\n\n> Architecture proposal, October 8, 2026. This is not a claim of an already validated deployment. Documented features, hypotheses and results still requiring measurement are kept separate.\n\n## The fourth parameter\n\nEarly orchestration strategies asked **which model** to use and **how much reasoning effort** to allocate. Roles add **what function** an agent should perform. A further decision remains: **which harness should execute that task?**\n\nThe operational configuration becomes **`model + effort + role + harness`**, rather than only model plus effort. This is not a complete score function: permissions, codebase, budget, context and availability remain hard eligibility constraints.\n\nEven with identical model weights, harness instructions, read outputs, editing tools and compaction strategies can change observed behavior. Model comparisons that ignore the execution surface can therefore confuse causes.\n\n## Controlled contrast: OpenAI in Codex and OMP\n\nCodex CLI and Oh My Pi can run compatible OpenAI-family models, depending on version and authentication. This creates a useful experiment: **same model, same effort, same task, different harness**.\n\nCodex has an integrated workflow for reading, editing, running commands, approvals and sandboxing. It is a reasonable initial candidate for complete implementations with tests and auditable delivery. [Codex](https://github.com/openai/codex).\n\nOMP, a Pi fork, includes specialized tools such as LSP integration, debugging and hash-anchored editing, along with multi-provider support and extensibility. It is an interesting candidate for references, symbol navigation and focused modifications. [OMP](https://github.com/can1357/oh-my-pi).\n\n**Neither product is proven superior by this feature comparison.** LSP can reduce exploration when supported by the language and environment, but add little to small or unindexed projects. Integrated workflows may improve consistency on longer assignments, but that too needs measurement. Maintainer-published benchmarks are not a substitute for tests on your own repository.\n\n| Dimension | Codex CLI | OMP | Question to test |\n| --- | --- | --- | --- |\n| Execution | Integrated tool and command loop | Specialized, extensible tooling | Which needs fewer human interventions? |\n| Exploration | Repository reading and search | Search and LSP when available | Which locates correct changes with fewer reads? |\n| Editing | Agent editing tools | Hash-anchored and structured edits | Which incurs fewer failed attempts? |\n| Context | Built-in session and compaction | Its own configurable session strategies | Which preserves task constraints? |\n| Safety | Sandbox and explicit approvals | Controls depend on setup and tools | Which enforces the same restrictions? |\n| Cost | Subscription quota or API, depending on access | Compatible subscription or separate API, depending on provider | Which lowers cost per accepted task? |\n\nThe **harness** and the **inference provider** are different choices. OMP authentication paths can change billing, model availability and limits. A Codex subscription and an OpenAI API key must not be assumed interchangeable. Record the effective model ID and authentication route before benchmarking. A harness alias is also insufficient: OpenCode V2, for example, separates its catalog ID from the `modelID` sent to the provider. Record both before claiming two runs used the same model. [Aliases and providers](https://opencode.ai/v2/docs/providers/).\n\n## Routing as a planning problem\n\nA coordinator choosing only the strongest model may waste capacity while using unsuitable tools. A more precise scheduler:\n\n1. **Classifies work:** exploration, implementation, refactor, debugging, testing, review or documentation.\n2. **Applies hard constraints:** permission boundaries, secrets, language, available tools, quotas, latency and required isolation.\n3. **Assigns a role:** owner, explorer, implementer, reviewer or verifier, each with explicit scope and output.\n4. **Evaluates model–harness pairs:** actual compatibility, effort settings, capabilities and evidence for the task type.\n5. **Executes and verifies:** isolated worktree, tests, diff, usage logs and human approval when needed.\n6. **Learns cautiously:** records outcomes, updates routing rules and retains a safe fallback.\n\nRoles are contracts, not decorations. A read-only reviewer must not gain write access merely because routing selects another CLI. Determine authorized actions **before** selecting the harness.\n\n## An initial routing matrix\n\n| Assignment | Role | Initial candidate | When to prefer it |\n| --- | --- | --- | --- |\n| Locate cross-module impact | Explorer | OMP | Working LSP and measured reduction in reads |\n| Fix a reproducible bug | Implementer | Codex | Higher accepted-resolution rate |\n| Symbol-level refactor | Specialized implementer | OMP | Verified structural edits and renames |\n| Cross-layer change | Implementer | Codex | Better consistency across tests and contracts |\n| Review a diff | Reviewer | Any eligible read-only harness | Fewer missed defects and lower review cost |\n| Recover a failed run | Diagnostic fallback | Another eligible harness | Evidence a tooling change helps |\n\nThese are **routing hypotheses**, not exclusive product capabilities. If empirical results disagree, update the matrix.\n\n## A portable task contract\n\nCross-harness delegation works best when the coordinator creates a provider-independent task envelope:\n\n```yaml\ntask_id: BUG-142\nrole: implementer\ngoal: \"Fix duplicate events without changing the HTTP contract\"\nrepository_ref: \"immutable-commit\"\nscope:\n writable: [\"src/events/**\", \"tests/events/**\"]\nconstraints:\n network: false\n secrets: none\n production_write: false\nacceptance:\n - \"regression tests pass\"\n - \"diff stays in scope\"\noutputs: [\"summary\", \"diff\", \"tests\", \"usage\", \"blockers\"]\n```\n\nThis contract must be translated into **actual** harness and operating-system enforcement. Writing `network: false` in YAML does not disable the network. A harness unable to satisfy critical constraints must be ineligible, no matter its benchmark score.\n\n## From proposed design to a contextual assignment\n\nOctober 12, 2026 update: the [V4 operational case](/en/entrada/caso-orca-cockpit-multiagente) now documents general direction with Opus, integration with Sol low and package coordination with Sol medium. LIVE implementation and auditing are split across different families. This establishes a policy adopted in one project, **not a validated automatic router or a measured performance advantage**. This article's proposed A/B experiment still awaits that validation.\n\nHarness verification also remains an eligibility condition. In the reviewed OMP 18.10.0 installation, role rules existed in configuration, but effective session loading and enforcement were not demonstrated; allowing LSP also left rename operations to be checked. A “read” label does not prove the absence of writes. Before assigning a read-only auditor, verify effective runtime behavior and negative actions, not just the configuration file.\n\nFor the same reason, a quota notice does not automatically change model, effort or provider. Technical-failure recovery and human quota management are separate decisions; neither authorizes seeking a route with weaker controls.\n\n## A/B benchmarking: isolate the harness effect\n\nFor paired tasks, hold constant the starting commit, fixtures, effective model version where possible, reasoning effort, functional instructions, scope, budget and acceptance checks. Record unavoidable differences in system prompts, tools and compaction, because **these are part of the experimental treatment**.\n\nUse representative tasks and at least three runs per configuration, fresh worktrees and no reused solutions. Measure:\n\n- **Quality:** accepted-task rate, tests, regressions, missed defects and diff quality.\n- **Efficiency:** attributable tokens and cost, tool calls, edit retries and time to acceptance.\n- **Operation:** human interventions, compactions, repeat reads, permission failures and recovery events.\n- **Safety:** attempted out-of-scope actions and actual enforcement of restrictions.\n\nThe central outcome is **total cost per accepted task**, including review, rework and failures, not simply patch-generation time. Where usage accounting differs between providers, report it separately and favor observed monetary cost and independently checked outcomes.\n\n## Fallback, learning and limits\n\nAn advanced router must avoid two traps: switching harnesses automatically on every error, and rewarding whichever agent reports success fastest. A logic failure is not necessarily a harness failure, and success requires independent acceptance.\n\nRecord `(task type, model, effort, harness, version, tools, permissions, outcome)` and update preferences only with meaningful samples. Infrastructure or tool failures can trigger compatible fallbacks. **Safety violations must stop and escalate**, not seek a more permissive harness.\n\nSwitching execution surfaces has costs too: setup, context reconstruction, logs and new failure modes. A consistent single-harness system can outperform a complex router at small scale.\n\n## From choosing the best model to choosing the best working environment\n\nThe point is not to accumulate CLIs, but to stop treating the harness as an invisible constant.\n\nA mature coordinator should ask: **Which model, effort, role and harness combination delivers a verifiable result for this task within its constraints and budget?**\n\nAnswer with portable contracts, reproducible experiments and accepted-task metrics, not brand loyalties. The harness becomes a planning variable rather than a terminal preference.\n\nFor the broader product comparison, see [Comparing CLI harnesses](/entrada/comparar-harness-cli-codex-claude-opencode-cline).\n", "language": "en" }, { "slug": "protocolos-humanos-cuota-rct-overdrive", "title": "RCT and Overdrive: human protocols for managing provider quotas", "summary": "Two prepared responses to scarce or expiring capacity: protect LIVE operations, prioritize useful BUILD work, and keep control with the human operator.", "type": "editorial", "order": 20, "tags": [ "providers", "quota", "protocols", "rct", "overdrive", "continuity", "operations", "governance" ], "related": [ "enrutamiento-modelo-esfuerzo-rol-harness", "guia-escalado-modelos", "comparar-harness-cli-codex-claude-opencode-cline", "orquestacion" ], "area": "Gobierno de agentes", "glyph": "◈", "hue": "rgba(237,195,94,.25)", "file": "protocolos-humanos-cuota-rct-overdrive.md", "html": "\n\nOperating framework defined in October 2026. These are human operator decisions, not an autonomous coordinator policy or a benchmark-validated optimization. Model names and commands refer to a specific setup.
\n
A well-planned round of work can face two opposite situations: too little quota to finish, or unused capacity that may expire at a reset. Improvising a response introduces rushed decisions at precisely the wrong moment.
\nRCT and Overdrive prepare that response in advance. The operator changes concurrency, priorities, and stopping points. Task complexity continues to determine the model and reasoning effort required.
\nThink of it as min-maxing provider capacity while preserving the controls that make the result reliable. The useful unit is an accepted task, resolved uncertainty, or reduced risk. Emptying a usage counter does not establish efficiency.
\nThis complements routing by model, effort, role, and harness. Routing selects the execution configuration; these protocols organize a round of work when provider availability changes.
\nA human operator activates and exits each protocol. The operator reads usage, interprets the availability window, chooses priorities, and decides whether and when to redeem a reset.
\nA coordinator can receive explicit instructions to reduce parallel work, prepare tests, record a recovery point, or present evidence. That does not authorize it to switch regimes, purchase capacity, expand permissions, or initiate a LIVE operation independently.
\nIn this version, notifying the team when usage crosses a threshold is part of human operation. A future automated alert would need a defined data source, freshness expectation, and recipient. An alert is not authorization.
\nBUILD covers isolated preparation: implementation in branches, tests using fixtures, documentation, audits, and preliminary reviews. LIVE covers operations with real effects: deployment, data migration, production configuration changes, or actions against an active service.
\nClassification follows effects and permissions. A test that writes to production is LIVE regardless of its name. A read-only audit can remain BUILD while still requiring careful handling of the data it accesses.
\nThis distinction allows more preparation without automatically accelerating publication. The LIVE gate retains its approval, evidence, and recovery requirements.
\n| Decision | \nRCT: scarce quota | \nOverdrive: expiring quota | \n
|---|---|---|
| Goal | \nSafe closure and continuity | \nUseful deliverables from available capacity | \n
| Concurrency | \nFewer fronts, favor work nearing closure | \nMore independent BUILD work within review capacity | \n
| Model and reasoning | \nPreserve task requirements | \nPreserve task requirements | \n
| LIVE work | \nAdmit only steps with completion and recovery margin | \nKeep the same gates; spare capacity is no justification to multiply them | \n
| Evidence | \nSafe point, receipt, and session record | \nVerifiable results and reviewable outputs | \n
| Regime authority | \nHuman operator | \nHuman operator | \n
The original protocol defines seven rules:
\nA usage percentage rarely predicts exactly how much work remains possible. Conservative estimates can use comparable operations plus uncertainty margin. If execution, verification, and recovery capacity cannot be justified, postpone LIVE work.
\nRecovery should not depend exclusively on the same model remaining available. A documented procedure a human can execute reduces that dependency. Some operations have no simple reversal; they need an appropriate recovery plan before becoming eligible.
\nThe receipt is a concise operational record:
\nThe pre-step receipt records preparation. Update it afterward with actual outcomes and evidence. Keep credentials out and distinguish plans from completed execution.
\nSession records preserve context, but the world can change while work is paused. Check branch and service state before resuming. Exact resumption means recovering a known point with evidence, not blindly replaying commands.
\nOverdrive applies when the operator has evidence that available quota will expire before being used. Verify the window for the actual account first. An ambiguous announcement or assumed reset time is not enough.
\nIn the originating setup, the instruction is /fast in all Codex terminals participating in the round. This records that setup's choice, not a promise of availability, speed, price, or quota consumption for every account. The operator checks command support, active mode, and provider conditions. A speed setting does not authorize a reasoning change.
As external context on October 12, 2026, Fast consumes included limits at 2.5 times the Standard rate; purchased credits and Enterprise pay-as-you-go are billed at twice Standard. Check which allowance the account uses before the round. Codex speed and usage.
\nCapacity goes toward more parallel BUILD work, audits, preliminary reviews, tests, and documentation. Each front needs an output and a closure condition: a regression test, impact report, focused diff, or operational guide checked against the code.
\nThe example keeps coordinators on Sol medium and Luna on high, following the operator's usual allocation. These are concrete assignments, not universal equivalences across model families. The exception allowing LIVE-gate auditors or difficult designs to move to high applies to assignments that start at medium; Luna is already high. Spare quota is not a reason for blanket escalation.
\nConcurrency adds integration cost. Isolate branches or worktrees, assign file ownership, and avoid duplicating investigations unless a comparison is intentional. Repeated audit findings provide little value without acceptance criteria and a reviewer.
\nContextual update, October 12, 2026: the Sol medium/Luna high preset above is preserved as part of the original human protocol. The V4 operational case now separates general direction with Opus, integration with Sol low and package coordination with Sol medium. That allocation serves different functions within that project; it does not automatically amend the protocol or establish a downgrade due to quota scarcity.
\nThe shared rule remains choosing effort by complexity and responsibility while preserving the task's permissions. Quota notices are informational: they do not activate RCT, Overdrive or a provider switch on their own. Likewise, previously authorized small LIVE autonomy does not arise from spare quota.
\nBefore opening another front, the operator should answer:
\nWhen review is saturated, more agents can turn expiring quota into review debt. Finish tests, consolidate documentation, or close existing work instead. Leaving capacity unused is also valid.
\nLow quota before a migration. One fix is almost complete, two investigations remain open, and a migration is pending. The operator activates RCT, closes the verifiable fix, and records the investigations. The migration waits unless validation and recovery have a defensible margin. Any available reset is redeemed at that safe boundary.
\nConfirmed window with unused capacity. A BUILD feature needs tests and review. The operator activates Overdrive and assigns independent regression, compatibility, diff-review, and documentation work. Outputs still pass through the same publication gate. None makes deployment automatic.
\nThese are application examples, not measured results. Evaluate the protocols through accepted closures, defects found before LIVE, resumption time, rework, and review load. Percentage consumed provides context rather than the primary success metric.
\nA minimal operator record could look like this:
\nprotocol: RCT # or Overdrive\nactivated_by: human_operator\nreason: \"Verified quota condition for this round\"\nquota_source_and_time: \"Record the actual observation\"\nreset_window: \"Confirmed or unknown; do not present a guess as fact\"\npriority_fronts: []\npreserved_configurations: []\nconcurrency_limit: \"Based on isolation and review capacity\"\nnext_safe_point: \"Verifiable reference\"\nexit_condition: \"Defined by the operator\"This is a proposed record, not a file that activates behavior by itself. Exit conditions may include reaching the intended closure, a change in availability, or exhausted review capacity. The operator evaluates them between safe steps.
\nUse RCT when safe closure and continuity dominate under scarce capacity. Use Overdrive when a confirmed window and useful, absorbable preparation backlog exist. Both retain task-level technical standards and explicit human responsibility.
\nThe goal is to let a provider event change work organization without forcing last-minute decisions about risk, permissions, and quality. Observation and recordkeeping may later be automated. Delegating regime decisions requires additional design and authorization.
\nRCT and Overdrive rules come from the human protocol behind this editorial. Receipts, the record template, and proposed metrics develop its application; they are not guaranteed native provider features.
\n", "headings": [ { "label": "Quota changes the shape of a work session", "depth": 2, "id": "quota-changes-the-shape-of-a-work-session" }, { "label": "Who makes the decision", "depth": 2, "id": "who-makes-the-decision" }, { "label": "BUILD and LIVE describe consequences", "depth": 2, "id": "build-and-live-describe-consequences" }, { "label": "RCT: protect closure under scarcity", "depth": 2, "id": "rct-protect-closure-under-scarcity" }, { "label": "A useful receipt", "depth": 3, "id": "a-useful-receipt" }, { "label": "Overdrive: use capacity without inventing work", "depth": 2, "id": "overdrive-use-capacity-without-inventing-work" }, { "label": "Protocol preset and project allocation", "depth": 3, "id": "protocol-preset-and-project-allocation" }, { "label": "Human review is a capacity limit", "depth": 3, "id": "human-review-is-a-capacity-limit" }, { "label": "Two practical scenarios", "depth": 2, "id": "two-practical-scenarios" }, { "label": "A short record before the round", "depth": 2, "id": "a-short-record-before-the-round" }, { "label": "Why decide in advance", "depth": 2, "id": "why-decide-in-advance" }, { "label": "Related reading", "depth": 3, "id": "related-reading" } ], "raw": "---\nslug: protocolos-humanos-cuota-rct-overdrive\ntitle: \"RCT and Overdrive: human protocols for managing provider quotas\"\ntype: editorial\norder: 20\nsummary: \"Two prepared responses to scarce or expiring capacity: protect LIVE operations, prioritize useful BUILD work, and keep control with the human operator.\"\ntags: [providers, quota, protocols, rct, overdrive, continuity, operations, governance]\nrelated: [enrutamiento-modelo-esfuerzo-rol-harness, guia-escalado-modelos, comparar-harness-cli-codex-claude-opencode-cline, orquestacion]\narea: Gobierno de agentes\nglyph: ◈\nhue: rgba(237,195,94,.25)\n---\n\n# RCT and Overdrive: human protocols for managing provider quotas\n\n> Operating framework defined in October 2026. These are human operator decisions, not an autonomous coordinator policy or a benchmark-validated optimization. Model names and commands refer to a specific setup.\n\n## Quota changes the shape of a work session\n\nA well-planned round of work can face two opposite situations: too little quota to finish, or unused capacity that may expire at a reset. Improvising a response introduces rushed decisions at precisely the wrong moment.\n\nRCT and Overdrive prepare that response in advance. The operator changes concurrency, priorities, and stopping points. Task complexity continues to determine the model and reasoning effort required.\n\nThink of it as *min-maxing* provider capacity while preserving the controls that make the result reliable. The useful unit is an accepted task, resolved uncertainty, or reduced risk. Emptying a usage counter does not establish efficiency.\n\nThis complements [routing by model, effort, role, and harness](/en/entrada/enrutamiento-modelo-esfuerzo-rol-harness). Routing selects the execution configuration; these protocols organize a round of work when provider availability changes.\n\n## Who makes the decision\n\n**A human operator activates and exits each protocol.** The operator reads usage, interprets the availability window, chooses priorities, and decides whether and when to redeem a reset.\n\nA coordinator can receive explicit instructions to reduce parallel work, prepare tests, record a recovery point, or present evidence. That does not authorize it to switch regimes, purchase capacity, expand permissions, or initiate a LIVE operation independently.\n\nIn this version, notifying the team when usage crosses a threshold is part of human operation. A future automated alert would need a defined data source, freshness expectation, and recipient. An alert is not authorization.\n\n## BUILD and LIVE describe consequences\n\n**BUILD** covers isolated preparation: implementation in branches, tests using fixtures, documentation, audits, and preliminary reviews. **LIVE** covers operations with real effects: deployment, data migration, production configuration changes, or actions against an active service.\n\nClassification follows effects and permissions. A test that writes to production is LIVE regardless of its name. A read-only audit can remain BUILD while still requiring careful handling of the data it accesses.\n\nThis distinction allows more preparation without automatically accelerating publication. The LIVE gate retains its approval, evidence, and recovery requirements.\n\n| Decision | RCT: scarce quota | Overdrive: expiring quota |\n| --- | --- | --- |\n| Goal | Safe closure and continuity | Useful deliverables from available capacity |\n| Concurrency | Fewer fronts, favor work nearing closure | More independent BUILD work within review capacity |\n| Model and reasoning | Preserve task requirements | Preserve task requirements |\n| LIVE work | Admit only steps with completion and recovery margin | Keep the same gates; spare capacity is no justification to multiply them |\n| Evidence | Safe point, receipt, and session record | Verifiable results and reviewable outputs |\n| Regime authority | Human operator | Human operator |\n\n## RCT: protect closure under scarcity\n\nThe original protocol defines seven rules:\n\n1. **Do not lower models or reasoning because quota is scarce.** Reduce scope or concurrency before weakening the configuration a task requires.\n2. **Before every LIVE step, establish a safe point and write a receipt to disk.** The previous state and recovery plan must be discoverable outside the chat.\n3. **Do not start a LIVE step unless remaining capacity covers it and its rollback.** Include verification and diagnosis, not just the happy-path command.\n4. **Open fewer fronts and prioritize those that close something.** An accepted small change can be worth more than five unfinished tasks.\n5. **Register sessions so work can resume from an identifiable state.** Preserve references, results, and the next step.\n6. **Redeem a reset between steps, never in the middle of one.** Finish the operation or reach a safe point first.\n7. **Notify when crossing a threshold around 5%.** This is an operator attention signal, not a universally sufficient reserve.\n\nA usage percentage rarely predicts exactly how much work remains possible. Conservative estimates can use comparable operations plus uncertainty margin. If execution, verification, and recovery capacity cannot be justified, postpone LIVE work.\n\nRecovery should not depend exclusively on the same model remaining available. A documented procedure a human can execute reduces that dependency. Some operations have no simple reversal; they need an appropriate recovery plan before becoming eligible.\n\n### A useful receipt\n\nThe receipt is a concise operational record:\n\n- Task identifier, responsible person, and timestamp.\n- Repository, branch or worktree, starting commit, and uncommitted changes.\n- Observed state and location of the safe point or backup where applicable.\n- Authorized step, scope, and planned verification.\n- Rollback or recovery procedure and how to access it.\n- Session or terminal reference, test results, and precise next action.\n\nThe pre-step receipt records preparation. Update it afterward with actual outcomes and evidence. Keep credentials out and distinguish plans from completed execution.\n\nSession records preserve context, but the world can change while work is paused. Check branch and service state before resuming. Exact resumption means recovering a known point with evidence, not blindly replaying commands.\n\n## Overdrive: use capacity without inventing work\n\nOverdrive applies when the operator has evidence that available quota will expire before being used. Verify the window for the actual account first. An ambiguous announcement or assumed reset time is not enough.\n\nIn the originating setup, the instruction is **`/fast` in all Codex terminals participating in the round**. This records that setup's choice, not a promise of availability, speed, price, or quota consumption for every account. The operator checks command support, active mode, and provider conditions. A speed setting does not authorize a reasoning change.\n\nAs external context on October 12, 2026, Fast consumes included limits at 2.5 times the Standard rate; purchased credits and Enterprise pay-as-you-go are billed at twice Standard. Check which allowance the account uses before the round. [Codex speed and usage](https://learn.chatgpt.com/docs/agent-configuration/speed).\n\nCapacity goes toward **more parallel BUILD work, audits, preliminary reviews, tests, and documentation**. Each front needs an output and a closure condition: a regression test, impact report, focused diff, or operational guide checked against the code.\n\nThe example keeps **coordinators on Sol medium and Luna on high**, following the operator's usual allocation. These are concrete assignments, not universal equivalences across model families. The exception allowing LIVE-gate auditors or difficult designs to move to high applies to assignments that start at medium; Luna is already high. Spare quota is not a reason for blanket escalation.\n\nConcurrency adds integration cost. Isolate branches or worktrees, assign file ownership, and avoid duplicating investigations unless a comparison is intentional. Repeated audit findings provide little value without acceptance criteria and a reviewer.\n\n### Protocol preset and project allocation\n\nContextual update, October 12, 2026: the Sol medium/Luna high preset above is preserved as part of the original human protocol. The [V4 operational case](/en/entrada/caso-orca-cockpit-multiagente) now separates general direction with Opus, integration with Sol low and package coordination with Sol medium. That allocation serves different functions within that project; it does not automatically amend the protocol or establish a downgrade due to quota scarcity.\n\nThe shared rule remains choosing effort by complexity and responsibility while preserving the task's permissions. Quota notices are informational: they do not activate RCT, Overdrive or a provider switch on their own. Likewise, previously authorized small LIVE autonomy does not arise from spare quota.\n\n### Human review is a capacity limit\n\nBefore opening another front, the operator should answer:\n\n- What useful output will it produce, and what decision will that enable?\n- Can it finish or reach a safe point within the window?\n- Is it independent enough to avoid blocking other work?\n- Who will review it, and when?\n\nWhen review is saturated, more agents can turn expiring quota into review debt. Finish tests, consolidate documentation, or close existing work instead. Leaving capacity unused is also valid.\n\n## Two practical scenarios\n\n**Low quota before a migration.** One fix is almost complete, two investigations remain open, and a migration is pending. The operator activates RCT, closes the verifiable fix, and records the investigations. The migration waits unless validation and recovery have a defensible margin. Any available reset is redeemed at that safe boundary.\n\n**Confirmed window with unused capacity.** A BUILD feature needs tests and review. The operator activates Overdrive and assigns independent regression, compatibility, diff-review, and documentation work. Outputs still pass through the same publication gate. None makes deployment automatic.\n\nThese are application examples, not measured results. Evaluate the protocols through accepted closures, defects found before LIVE, resumption time, rework, and review load. Percentage consumed provides context rather than the primary success metric.\n\n## A short record before the round\n\nA minimal operator record could look like this:\n\n```yaml\nprotocol: RCT # or Overdrive\nactivated_by: human_operator\nreason: \"Verified quota condition for this round\"\nquota_source_and_time: \"Record the actual observation\"\nreset_window: \"Confirmed or unknown; do not present a guess as fact\"\npriority_fronts: []\npreserved_configurations: []\nconcurrency_limit: \"Based on isolation and review capacity\"\nnext_safe_point: \"Verifiable reference\"\nexit_condition: \"Defined by the operator\"\n```\n\nThis is a proposed record, not a file that activates behavior by itself. Exit conditions may include reaching the intended closure, a change in availability, or exhausted review capacity. The operator evaluates them between safe steps.\n\n## Why decide in advance\n\nUse RCT when safe closure and continuity dominate under scarce capacity. Use Overdrive when a confirmed window and useful, absorbable preparation backlog exist. Both retain task-level technical standards and explicit human responsibility.\n\nThe goal is to let a provider event change work organization without forcing last-minute decisions about risk, permissions, and quality. Observation and recordkeeping may later be automated. Delegating regime decisions requires additional design and authorization.\n\n### Related reading\n\n- [Choosing models and reasoning effort](/en/entrada/guia-escalado-modelos): match effort to the task.\n- [Model, effort, role, and harness](/en/entrada/enrutamiento-modelo-esfuerzo-rol-harness): allocate execution configurations.\n- [Comparing CLI harnesses](/en/entrada/comparar-harness-cli-codex-claude-opencode-cline): tools, permissions, and continuity.\n\nRCT and Overdrive rules come from the human protocol behind this editorial. Receipts, the record template, and proposed metrics develop its application; they are not guaranteed native provider features.\n", "language": "en" }, { "slug": "orca-como-ade", "title": "Orca as an ADE and control plane", "summary": "Orca organizes agents, repositories and execution environments; it does not replace the model or decide on its own how the team should work.", "type": "concept", "order": 1, "tags": [ "orca", "ade", "agents", "control-plane" ], "related": [ "workspaces-y-worktrees", "orquestacion", "agent-terminals" ], "area": "Orca", "glyph": "◉", "hue": "rgba(237,195,94,.25)", "file": "01-orca-como-ade.md", "html": "\n\nExternal product documentation reviewed on October 12, 2026. Historical cases and local operating choices are preserved.
\n
Orca is an Agent Development Environment: an interface for running and supervising different coding agents on real projects, with identifiable sessions and workspaces. The terminal remains a central surface, but it is no longer the only one: Orca documents an experimental Chat UI for supported agents. WSL and SSH sessions use a terminal-backed variant; do not assume parity with local structured chat.
\nIt does not bring a new “brain”. The brains are still Codex, Claude Code, OpenCode, Pi or other CLI agents. Orca provides the place where you can see who is working, on which branch, on which host and in what state.
\nWhen agents live in loose terminals, coordination stays in the operator’s memory:
\nOrca makes that state visible and ties it to concrete entities: project, workspace, worktree, terminal, session and host.
\nThe executor: Codex, Claude Code, OpenCode or another CLI. It reasons, uses tools and modifies files according to its permissions.
\nThe machine where the repository, Git, dependencies and credentials actually live. It can be the local PC, WSL, a machine over SSH or a remote Orca Server.
\nThat is Orca Desktop. It lets you open, arrange, observe and resume work without necessarily moving the code to the machine you are looking from.
\nSeparating these planes is the first big conceptual win: the interface can close or change devices without the development environment having to move.
\nOrca enables parallel work, but it does not guarantee good orchestration. Five agents open in five panes can produce five times more conflict if they share scope, branch or sensitive files.
\nThe value shows up when you add a methodology:
\nOrca makes sense when there are several simultaneous projects, agents or tasks; when the environment runs on Linux but the interface is used from Windows; or when you need to recover context after frequent interruptions.
\nFor a single quick question in a small repository, a regular terminal may be enough. Orca starts paying for its complexity when the problem stops being “talking to an agent” and becomes managing a work system with agents.
\nThe goal is not to have more agents switched on. It is to increase useful parallel work without losing traceability, isolation or the ability to stop.
\nProject, workspace and worktree look alike, but they serve different purposes. Understanding that separation avoids the classic disaster of several agents editing the same checkout.
\nThe stable reference to the repository or related set of repositories. It groups the different work fronts and lets you apply shared configuration.
\nA project should not represent a temporary task. It is the durable container that workspaces are born from.
\nThe visible operating unit in Orca: a place with tabs, panes, terminals, editors and, usually, an associated task or front.
\nThe visual hierarchy between workspaces helps organize the operation, but it does not change Git history on its own. A child workspace can express dependency or coordination without implying a stacked branch.
\nThe real isolation provided by Git. Each worktree has:
\nThat is why Orca is worktree-native: each feature, fix or audit can live in a separate working copy without requiring stash, constant branch switching or competition over the same files. The expected cycle is create, work, review, merge and archive.
Holds the full project context, reviews state and prepares the plan. It is not used as an indiscriminate dump for parallel implementations.
\nEach one gets a concrete task, a branch and a file scope. The agent can work autonomously within that boundary.
\nChecks diffs, tests and compatibility before merging. It can be the main one or a dedicated one depending on the risk.
\nBefore launching an agent, make these explicit:
\nA new worktree does not automatically inherit everything Git ignores. Dependencies, caches and local secrets may need specific setup. Orca lets you share large directories or copy ignored files into each worktree, but it is worth distinguishing:
\nLockfiles, migrations, infrastructure and cross-cutting configuration should have a single owner per work window.
\nIsolation does not only prevent technical conflicts. It also makes it easier to compare alternatives, drop one implementation and keep another, or audit a change without dirtying the main checkout.
\n\n\nExternal product documentation reviewed on October 12, 2026. Historical cases and local operating choices are preserved.
\n
Opening several agents at once increases capacity, but it does not define who decides, what depends on what, or when a task is really finished.
\nThere is orchestration when, at a minimum, there is:
\nThe pattern you can apply today with regular workspaces and terminals:
\nThe initial case required human intervention for every production step. In its V4 evolution, reviewed on October 12, 2026, certain small LIVE operations have previously bounded autonomy; others, such as deletions, still require explicit permission. Project policy defines that boundary: opening an Orca terminal does not grant authority. The cockpit case details the current separation between general direction, integration and package coordination.
\nThis layer does not depend on an experimental feature. Its authority lives in the work contract, Git and the review process.
\nOrca includes a structured layer, currently experimental, based on:
\nThis option is useful when it matters to follow a task graph, record ownership or require every worker to formally close its dispatch. For a one-off prompt watched by a person, a regular terminal is still enough.
\nCurrent documentation requires enabling the experimental feature and uses run-create, tasks and worker-start. The old orchestration run and run-stop commands are retired. A Run preserves coordination context; it does not place or schedule workers by itself. Consult orca skills get orchestration --full in the installation you will use before copying commands from another version. Official flow.
The manager should not become the universal implementer. Its value lies in:
\nThe more it writes directly on every front, the more it loses the separation that makes the system useful.
\nDelegation works well for tasks that can be described with a clear boundary: implementing an endpoint, auditing a module, writing tests, comparing alternatives or verifying a migration.
\nIt is best to keep centralized the decisions that cut across several branches: lockfiles, shared schemas, secrets, migrations, deployments and architecture changes.
\nA delivery should answer:
\n“Done” without evidence is not completion; it is just a notification.
\nWith an SSH host, Orca separates the place you control from the place where the work runs.
\nThe interface can be on Windows or a laptop, while the repository, Git, Node, Python, Docker and the CLI agents live on Linux/WSL or on a more powerful remote machine.
\nThis separation avoids duplicating environments and cuts down on “works on my machine”: every client can connect to the same development host.
\nAn SSH host lets Orca open and manage workspaces directly on another machine over SSH.
\nA Remote Orca Server is another Orca runtime instance prepared for paired clients and more federated scenarios. To use local WSL from Orca Desktop, the simple pattern is an SSH connection over the loopback interface.
\nThe current documentation, checked on October 12, 2026, also describes an Orca-managed server inside the SSH host, installed on first connection when the host supports it, with compatibility and migration paths for existing sessions. The distinction above is between connection modes, not between having a server and having none. This describes the current product; it does not establish that an existing installation has already migrated. SSH worktrees
\nOn the main desktop:
\nFor portable access:
\nA dedicated key lets you revoke a laptop without breaking GitHub, a VPS or other access. It also makes it easier to audit which device still holds authorization.
\nThe private key stays on the client; the host only receives the public one in authorized_keys.
The remote client does not create availability. If the host is off, suspended, offline or WSL never started after a reboot, there is no environment to connect to.
\nAvailability has to be checked layer by layer:
\nThe laptop stops being a second development station that has to be kept in sync. It becomes another window into the same environment, with the same repositories, sessions and credentials.
\n\n\nExternal product documentation reviewed on October 12, 2026. Historical cases and local operating choices are preserved.
\n
In Orca, an agent session is a CLI running inside a specific terminal and worktree. That link lets the system show identity and state without forcing the operator to open every pane.
\nA regular terminal only exposes input and output. An agent terminal adds operational context:
\nTabs organize different surfaces inside a workspace. Panes let you see several at once. A split can be used for:
\nThe layout helps you observe; it does not replace isolation. Two agents in different panes are still dangerous if they write to the same checkout and the same scope.
\nOrca recognizes lifecycle changes through terminal signals and agent hooks. In operational terms, the important states are:
\nAgent Dashboard must be enabled under Settings → Experimental. Worktree-row indicators remain available without that board. The dashboard lets you supervise several agents by exception: deal first with the ones that need intervention and review the ones that finished, without going pane by pane.
\nIn our environment we confirmed that several shells can share a workspace and worktree, but each pane keeps its own identifiers such as ORCA_PANE_KEY, ORCA_TAB_ID and ORCA_TERMINAL_HANDLE.
That enables an external observability layer: relating descendant processes to a specific pane, detecting whether Codex or OpenCode is running there and representing the state without writing to the project.
\nCopying a bounded stretch of scrollback is useful for transferring recent evidence to another tool. It should not be the main continuity strategy: transcripts grow, get truncated and mix reasoning with operational noise.
\nA durable handoff should summarize decisions, files, tests, risks and the next step. The terminal keeps the detail; the documentation keeps the useful state.
\nLaunch defaults can change and, currently, Orca favors highly autonomous agents inside the worktree. If the team needs manual confirmation, it must explicitly configure and verify the actual arguments of each agent.
\nThe worktree reduces the blast radius on files, but on its own it does not limit access to the network, secrets, system commands or external services.
\nContinuity is not a chat staying open. It is being able to answer, after an interruption:
\nOrca restores workspaces, tabs, splits, focus and scrollback. As long as the host daemon survives, it can also keep agent processes alive even if the Desktop window closes or restarts.
\nIf the whole host goes down —reboot, power cut, kernel panic— the processes end. When it comes back, the layout and the last scrollback can be restored, but not the execution that was in memory.
\nThat is why there are three different levels:
\nOnly the third one survives a total outage independently and lets you rebuild with confidence.
\nIn real recoveries we had to tell apart a crashed interface, a stopped Orca service, an agent that was still alive and a healthy worktree whose conversation could no longer be resumed.
\nBefore killing processes or cleaning up workspaces, it pays to look at the state of the runtime, the session, the branch, the worktree and Git. The goal is not to rebuild the whole infrastructure from memory: it is to identify which layer failed and preserve the ones that are still healthy.
\nThe rule is simple: identify first, intervene second.
\nThe October 12, 2026 operational case review reinforces a step before relaunching: reconstruct open or merged PRs, branches and worktrees, workers still running and actual deployments. The last conversation summary is a lead, not a substitute for that inspection. If work already exists or is still running, opening another worker can duplicate it or create competition for the same resource.
\nThe handoff must also distinguish locally ready, applied and accepted. An integrated change may still await publication; a published change may need the next real cycle to confirm its objective. When work remains, record its owner, missing evidence and next step. A finished process or delivery to the operator does not prove the original need has been resolved.
\nThis evolves the multi-agent case; it is not an Orca recovery guarantee. Operational state must be verified outside the interface.
\nOrca’s stable identifiers let you relate workspace, worktree, tab and terminal to the process running there. That relationship is enough to build read-only observability without controlling the agent’s session.
\nThis was the basis for visualizing agents outside Orca without controlling or modifying their sessions. Observability stays separate from operational authority.
\nEvery important stage of work should leave a short summary outside the scrollback:
\nThe transcript explains how you got here. The handoff says where you are.
\nRecovery stops being “open windows until something looks familiar”. It becomes a layer-by-layer diagnosis that lets you preserve live agents, rescue work and avoid destructive clean-ups driven by anxiety. Nothing worse than killing the wrong manager in a hurry.
\nOrca Desktop can live on Windows while the real work runs inside WSL. The separation keeps a native interface without moving repositories, dependencies and CLIs onto the Windows filesystem.
\n| Layer | \nResponsibility | \n
|---|---|
| Windows | \nOrca interface and host selection | \n
| WSL/Linux | \nGit, repositories, runtimes and CLI agents | \n
| Local SSH | \nControlled bridge between the interface and the environment | \n
Projects stay inside the WSL filesystem. This reduces friction with permissions, watchers, performance and tools designed for Linux.
\nOrca uses a dedicated key. There is no need to reuse a personal identity with broader reach: a specific credential simplifies revocation and auditing.
\nEach CLI must be installed and authenticated inside WSL. A tool working on Windows does not mean it exists, or shares a session, inside Linux.
\nBefore enabling edits, ask the agent to identify the framework and cite the file where it checked. The test simultaneously proves the connection, path, CLI and repository access without modifying anything.
\nThe exact commands depend on the distribution, the WSL version and the security policy. The guide keeps the design; the implementation gets validated against each tool’s current documentation.
\n", "headings": [ { "label": "The pattern", "depth": 2, "id": "the-pattern" }, { "label": "Important decisions", "depth": 2, "id": "important-decisions" }, { "label": "Repositories on Linux", "depth": 3, "id": "repositories-on-linux" }, { "label": "A dedicated SSH identity", "depth": 3, "id": "a-dedicated-ssh-identity" }, { "label": "Agents installed on the real host", "depth": 3, "id": "agents-installed-on-the-real-host" }, { "label": "First test in read-only mode", "depth": 3, "id": "first-test-in-read-only-mode" }, { "label": "Preparing parallel work", "depth": 2, "id": "preparing-parallel-work" }, { "label": "Portable checklist", "depth": 2, "id": "portable-checklist" } ], "raw": "---\nslug: setup-windows-wsl\ntitle: Orca Desktop with Windows and WSL\ntype: guide\norder: 7\nsummary: A reference pattern for separating the desktop interface from the Linux environment where repositories, runtimes and agents live.\ntags: [orca, setup, windows, wsl, ssh]\nrelated: [hosts-ssh, agent-terminals, acceso-portatil-orca]\narea: Orca\nglyph: ⊞\nhue: rgba(168,106,255,.24)\n---\n\n# Orca Desktop with Windows and WSL\n\n## The pattern\n\nOrca Desktop can live on Windows while the real work runs inside WSL. The separation keeps a native interface without moving repositories, dependencies and CLIs onto the Windows filesystem.\n\n| Layer | Responsibility |\n| --- | --- |\n| Windows | Orca interface and host selection |\n| WSL/Linux | Git, repositories, runtimes and CLI agents |\n| Local SSH | Controlled bridge between the interface and the environment |\n\n## Important decisions\n\n### Repositories on Linux\n\nProjects stay inside the WSL filesystem. This reduces friction with permissions, watchers, performance and tools designed for Linux.\n\n### A dedicated SSH identity\n\nOrca uses a dedicated key. There is no need to reuse a personal identity with broader reach: a specific credential simplifies revocation and auditing.\n\n### Agents installed on the real host\n\nEach CLI must be installed and authenticated inside WSL. A tool working on Windows does not mean it exists, or shares a session, inside Linux.\n\n### First test in read-only mode\n\nBefore enabling edits, ask the agent to identify the framework and cite the file where it checked. The test simultaneously proves the connection, path, CLI and repository access without modifying anything.\n\n## Preparing parallel work\n\n- one worktree and one branch per task;\n- a single owner for shared resources;\n- scope and validations written down before running;\n- human review before merge or deploy;\n- credentials limited to the host and project that need them.\n\n## Portable checklist\n\n- [ ] The Linux environment’s SSH service is running.\n- [ ] Orca uses a dedicated key.\n- [ ] The local host connects without depending on an open terminal.\n- [ ] Repositories are opened from the Linux filesystem.\n- [ ] Agents are available and authenticated on that host.\n- [ ] The read-only test finished with a clean Git state.\n- [ ] The worktree strategy is defined.\n\nThe exact commands depend on the distribution, the WSL version and the security policy. The guide keeps the design; the implementation gets validated against each tool’s current documentation.\n", "language": "en" }, { "slug": "acceso-portatil-orca", "title": "Portable access to Orca over a private network", "summary": "Use another device as a client of the same development environment, without duplicating repositories or exposing SSH to the Internet.", "type": "guide", "order": 8, "tags": [ "orca", "tailscale", "ssh", "wsl", "remote", "security" ], "related": [ "hosts-ssh", "setup-windows-wsl", "tailscale-red-privada-identidad", "tailscale-entorno-agentes" ], "area": "Orca", "glyph": "↗", "hue": "rgba(87,217,232,.22)", "file": "08-acceso-portatil.md", "html": "Work from a laptop on the same environment, repositories and agents that live on the main workstation.
\nThe portable device does not recreate the stack or keep parallel clones. It acts as an Orca client and connects over SSH through a private network.
\nThe client points to a stable private identity of the host, not to an ephemeral internal address. This avoids reconfiguring the connection after reboots or network changes.
\nThe laptop should only be able to open connections to the development host and the port it needs. Other servers and destinations stay out of reach.
\nThe device’s everyday user does not need the ability to modify the private network’s rules. Authorized connectivity and administering that connectivity are different permissions.
\nValidate that the allowed host responds and that an explicitly blocked destination is unreachable. Testing against a machine that is switched off does not prove the policy works.
\nRemote access depends on the host being on, connected and with the execution environment started. The private network does not replace a remote power-on or system recovery strategy.
\nMobility stops creating a second development station. There is a single Git state, a single credentials policy and the same agents seen from another client.
\nA digital transformation project combined integrations, data, APIs, security and production operations. A single conversation could hold the context, but it became a bottleneck as soon as several fronts opened in parallel.
\nLaunching agents without structure did not work either: it increased the risk of overlapping changes, contradictory decisions and lost context when switching sessions.
\nA higher-capability agent operates on the main workspace. Its job is to:
\nThe coordinator does not exist to implement everything. It exists so every task starts with enough context and comes back with comparable evidence.
\nBounded tasks are assigned according to cost, availability and each agent’s strengths. Different models and CLIs can coexist without changing the methodology.
\nEach worker gets:
\nReview agents are kept separate, when appropriate, from those who did the implementation.
\nThe V4 documentation, reviewed on October 12, 2026, separates responsibilities previously concentrated in one coordinator. The earlier design remains part of the case history; the current allocation distinguishes three levels:
\n| Level | \nAssignment in this environment | \nResponsibility | \n
|---|---|---|
| General direction | \nOpus | \nConversation with the human operator, priorities and cross-cutting decisions | \n
| Integration | \nSol at low effort | \nReconstruct state, order dependencies and integrate package evidence | \n
| Package coordination | \nSol at medium effort | \nLead a bounded capability through acceptance | \n
These are project assignments, not universal recommendations or model equivalences. LIVE implementation uses Luna at high effort or Sonnet; auditing switches to the opposite model family. Different families add review diversity, but do not guarantee error detection or replace tests.
\nThe unit remains one capability, one task, one branch and one worktree. BUILD/LIVE and the three-part gate already existed in V3: parity with CRM behavior, prepared recovery and auditing. V4 changes authority allocation and permits small LIVE operations within a previously authorized scope, with verification and bounded automatic rollback. Deletions and tombstones, the records marking deletion, require explicit human permission. A repository rule does not grant permissions in another session or tool.
\nGeneral direction receives a decision queue grouped by urgency: incidents, unblocking decisions and non-urgent matters. The integrator gathers evidence; it does not interrupt the person for every update or treat a pending decision as implied permission.
\nThe current circuit distinguishes locally ready, applied and accepted. A merged PR proves integration; an immediate postflight proves only the behavior it actually measured. Natural acceptance requires observing the agreed real operating cycle. If work remains, the handoff retains the remainder, its owner and the missing evidence: handing a problem to another person does not resolve it.
\nResumption also requires reconstructing actual PRs, branches, workers and deployments before opening new work. This prevents duplicating an implementation that kept advancing while the conversation was closed.
\nThis update summarizes anonymized project documentation and records reviewed on October 12. It is not a fresh execution of those tests or universal validation of the controls. Role contracts must be checked against effective runtime permissions, as explained in the environment is the policy.
\nFronts stopped being anonymous terminals. Each one was tied to a project, worktree, agent and visible state.
\nDifferent CLIs coexisted on the same surface. The model could be chosen per task without losing the overall map of the project.
\nImplementations did not compete for the same checkout. Each branch could be reviewed, compared or discarded without contaminating the main work.
\nSeparating interface, process, session, worktree and persistent state made it possible to recover work after interruptions without assuming everything was still alive or taking destructive actions by reflex.
\nThe interface worked as a cockpit while repositories and agents stayed in a central execution environment. Other devices could act as windows onto the same state, without creating divergent copies.
\nThe improvement did not come from “using many models”. It came from designing a system where models can be swapped, tasks stay isolated and the important context does not depend on any of them.
\nOrca made that architecture visible and operable. The quality of the result still depended on work contracts, Git, validations and human supervision.
\n\n\n", "headings": [ { "label": "Starting point", "depth": 2, "id": "starting-point" }, { "label": "The initial model", "depth": 2, "id": "the-initial-model" }, { "label": "Coordinating agent", "depth": 3, "id": "coordinating-agent" }, { "label": "Implementers and reviewers", "depth": 3, "id": "implementers-and-reviewers" }, { "label": "Initial operational flow", "depth": 2, "id": "initial-operational-flow" }, { "label": "Case evolution: V4, October 2026", "depth": 2, "id": "case-evolution-v4-october-2026" }, { "label": "From merge to accepted outcome", "depth": 3, "id": "from-merge-to-accepted-outcome" }, { "label": "What Orca contributed", "depth": 2, "id": "what-orca-contributed" }, { "label": "Understandable parallelism", "depth": 3, "id": "understandable-parallelism" }, { "label": "Vendor freedom", "depth": 3, "id": "vendor-freedom" }, { "label": "Real isolation", "depth": 3, "id": "real-isolation" }, { "label": "Continuity", "depth": 3, "id": "continuity" }, { "label": "Remote operation", "depth": 3, "id": "remote-operation" }, { "label": "Benefits", "depth": 2, "id": "benefits" }, { "label": "The transferable lesson", "depth": 2, "id": "the-transferable-lesson" } ], "raw": "---\nslug: caso-orca-cockpit-multiagente\ntitle: Case study — Orca as a multi-agent cockpit\ntype: case-study\norder: 9\nsummary: The evolution from one coordinator to separate direction, integration and packages, with cross-family auditing and verifiable acceptance.\ntags: [orca, case-study, multi-agent, worktrees, orchestration]\nrelated: [orquestacion, workspaces-y-worktrees, continuidad-y-observabilidad]\narea: Orca\nglyph: ◈\nhue: rgba(236,95,189,.24)\n---\n\n# Case study — Orca as a multi-agent cockpit\n\n## Starting point\n\nA digital transformation project combined integrations, data, APIs, security and production operations. A single conversation could hold the context, but it became a bottleneck as soon as several fronts opened in parallel.\n\nLaunching agents without structure did not work either: it increased the risk of overlapping changes, contradictory decisions and lost context when switching sessions.\n\n## The initial model\n\n### Coordinating agent\n\nA higher-capability agent operates on the main workspace. Its job is to:\n\n- review the overall state;\n- keep current decisions and constraints;\n- prepare the plan;\n- split the work into verifiable units;\n- review implementations and audits;\n- decide the next front.\n\nThe coordinator does not exist to implement everything. It exists so every task starts with enough context and comes back with comparable evidence.\n\n### Implementers and reviewers\n\nBounded tasks are assigned according to cost, availability and each agent’s strengths. Different models and CLIs can coexist without changing the methodology.\n\nEach worker gets:\n\n- its own worktree and branch;\n- an explicit scope;\n- operational constraints;\n- completion conditions;\n- an expected way of delivering evidence.\n\nReview agents are kept separate, when appropriate, from those who did the implementation.\n\n## Initial operational flow\n\n1. The coordinator inspects the project and prepares a task.\n2. A worktree is created from a known base.\n3. The implementer works within its scope.\n4. It delivers changes, tests, risks and open items.\n5. Another agent or the coordinator reviews the result.\n6. Merging and any production action stay behind a human gate.\n\n## Case evolution: V4, October 2026\n\nThe V4 documentation, reviewed on October 12, 2026, separates responsibilities previously concentrated in one coordinator. The earlier design remains part of the case history; the current allocation distinguishes three levels:\n\n| Level | Assignment in this environment | Responsibility |\n| --- | --- | --- |\n| General direction | Opus | Conversation with the human operator, priorities and cross-cutting decisions |\n| Integration | Sol at low effort | Reconstruct state, order dependencies and integrate package evidence |\n| Package coordination | Sol at medium effort | Lead a bounded capability through acceptance |\n\nThese are project assignments, not universal recommendations or model equivalences. LIVE implementation uses Luna at high effort or Sonnet; auditing switches to the opposite model family. Different families add review diversity, but do not guarantee error detection or replace tests.\n\nThe unit remains one capability, one task, one branch and one worktree. **BUILD/LIVE and the three-part gate already existed in V3**: parity with CRM behavior, prepared recovery and auditing. V4 changes authority allocation and permits small LIVE operations within a previously authorized scope, with verification and bounded automatic rollback. Deletions and tombstones, the records marking deletion, require explicit human permission. A repository rule does not grant permissions in another session or tool.\n\nGeneral direction receives a decision queue grouped by urgency: incidents, unblocking decisions and non-urgent matters. The integrator gathers evidence; it does not interrupt the person for every update or treat a pending decision as implied permission.\n\n### From merge to accepted outcome\n\nThe current circuit distinguishes **locally ready, applied and accepted**. A merged PR proves integration; an immediate postflight proves only the behavior it actually measured. Natural acceptance requires observing the agreed real operating cycle. If work remains, the handoff retains the remainder, its owner and the missing evidence: handing a problem to another person does not resolve it.\n\nResumption also requires reconstructing actual PRs, branches, workers and deployments before opening new work. This prevents duplicating an implementation that kept advancing while the conversation was closed.\n\nThis update summarizes anonymized project documentation and records reviewed on October 12. It is not a fresh execution of those tests or universal validation of the controls. Role contracts must be checked against effective runtime permissions, as explained in [the environment is the policy](/en/entrada/modelos-guiados-el-entorno-es-la-politica).\n\n\n## What Orca contributed\n\n### Understandable parallelism\n\nFronts stopped being anonymous terminals. Each one was tied to a project, worktree, agent and visible state.\n\n### Vendor freedom\n\nDifferent CLIs coexisted on the same surface. The model could be chosen per task without losing the overall map of the project.\n\n### Real isolation\n\nImplementations did not compete for the same checkout. Each branch could be reviewed, compared or discarded without contaminating the main work.\n\n### Continuity\n\nSeparating interface, process, session, worktree and persistent state made it possible to recover work after interruptions without assuming everything was still alive or taking destructive actions by reflex.\n\n### Remote operation\n\nThe interface worked as a cockpit while repositories and agents stayed in a central execution environment. Other devices could act as windows onto the same state, without creating divergent copies.\n\n## Benefits\n\n- more simultaneous fronts without sharing working files;\n- context continuity even when the implementer changed;\n- model selection by cost and task type;\n- clearer, reviewable handoffs;\n- less dependence on a particular session or interface;\n- explicit separation between planning, implementation, auditing and production.\n\n## The transferable lesson\n\nThe improvement did not come from “using many models”. It came from designing a system where models can be swapped, tasks stay isolated and the important context does not depend on any of them.\n\nOrca made that architecture visible and operable. The quality of the result still depended on work contracts, Git, validations and human supervision.\n\n> Case based on a real environment. Company names, repositories, infrastructure, identifiable incidents and operational data have been removed.\n", "language": "en" }, { "slug": "planificar-workstation-am5-escalable", "title": "Planning a scalable AM5 workstation", "summary": "How to audit an existing PC and migrate to AM5 across three stages — budget, mid-range and high-end — without rebuying half the machine at each step.", "type": "guide", "order": 9, "tags": [ "hardware", "am5", "workstation", "ryzen", "wsl", "agents", "upgrade" ], "related": [ "setup-windows-wsl", "orquestacion", "agent-terminals" ], "area": "Orca", "glyph": "◈", "hue": "rgba(168,106,255,.24)", "file": "planificar-workstation-am5-escalable.md", "html": "Case based on a real environment. Company names, repositories, infrastructure, identifiable incidents and operational data have been removed.
\n
\n\nExternal references reviewed on October 12, 2026. Specific models are architectural references, not a permanent shopping list. Before buying, validate prices, BIOS support, memory QVL, physical clearances and power requirements against current manufacturer documentation.
\n
A scalable migration is not about building three separate PCs. It is about defining one final machine and building toward it in stages.
\nThe classic mistake is to buy a complete budget configuration, replace half of it to reach mid-range, and replace much of it again to reach high-end. This guide reverses that logic:
\n\n\nDo not buy a component in one stage if you already know it will have to be replaced in the next, except for a deliberately temporary part.
\n
On AM5, that temporary part can be the entry CPU. Motherboard, memory, storage, case, cooling and power supply should be selected with the final destination in mind from day one.
\nThis pattern came from evaluating a still-capable AM4 workstation: an eight-core Ryzen 7, X570, 32 GB of DDR4, an RTX 30-series GPU, a fast NVMe drive and a good-quality 850 W PSU. The conclusion was not “replace everything”, but rather separate what had aged from what still retained value.
\nBefore choosing a Ryzen, inventory the machine. The question is not only what do I have?, but what can cross platforms without becoming a bottleneck or a risk?
\n| Component | \nWhat to record | \nValidation question | \n
|---|---|---|
| CPU | \nmodel, cores, power and typical load | \nIs CPU actually the current limit? | \n
| Motherboard | \nsocket, chipset, BIOS, slots and connectivity | \nDoes it force a platform change? | \n
| RAM | \ncapacity, module count, speed and peak usage | \nIs current capacity already being exhausted? | \n
| GPU | \nmodel, power and target resolution | \nDoes it need to change now, or can it migrate? | \n
| PSU | \nexact model, wattage, age and connectors | \nDoes it have the quality and headroom for the final build? | \n
| Cooler | \nmodel, socket support and thermal capacity | \nDoes it support AM5 and the final CPU? | \n
| NVMe/SATA | \nmodel, health, capacity and role | \nCan it remain as a primary or secondary drive? | \n
| Case | \nform factor, airflow and clearances | \nWill future motherboard, GPU and cooling fit? | \n
| PCIe/USB devices | \ncards, DACs, capture devices, networking, docks | \nDoes the new board provide enough lanes and ports? | \n
| System | \nWindows/Linux, WSL, VMs, Docker, agents | \nWhich resource actually saturates during real work? | \n
For a development and agent workstation, observe at least:
\nIf 32 GB of RAM is hitting the ceiling while the GPU remains comfortable, replacing the GPU first would be a very expensive upgrade to the wrong component.
\nChanging sockets forces replacement of CPU + motherboard + RAM. It does not automatically mean replacing everything else.
\nA modern PCIe GPU, a healthy NVMe drive, a suitable case and a good-quality ATX PSU can usually migrate. A cooler may migrate if the manufacturer provides AM5 compatibility or the required mounting hardware.
\nThe PSU deserves special review: “850 W” alone is not enough. Exact model, quality, age, protections, connectors and the final GPU all matter.
\nDDR4 memory does not migrate. AM5 uses DDR5.
\nThe following matrix does not describe three independent builds. It describes three states of the same workstation.
\n| Part | \nBudget | \nMid-range | \nHigh-end | \n
|---|---|---|---|
| CPU | \nRyzen 5 9600X | \nkeep the 9600X or upgrade only for a measured need | \nRyzen 9 9950X3D / 9950X3D2 depending on workload and price | \n
| Motherboard | \nsolid B850 | \nsame board | \nsame board, or X870E only if the I/O was justified from the start | \n
| RAM | \n64 GB DDR5, 2×32 | \nsame | \n64 GB or 128 GB if measurements justify it | \n
| GPU | \nreuse a still-capable GPU | \nkeep | \nupgrade later based on workload | \n
| NVMe | \nreuse a healthy drive | \nadd capacity | \nGen5 only if the workload benefits | \n
| PSU | \nreuse if it passes the audit | \nsame | \nreplace only if final CPU/GPU requirements demand it | \n
| Cooler | \nbuy with final CPU headroom | \nsame | \nsame if correctly sized | \n
| Case | \nreuse if suitable | \nsame | \nsame | \n
The goal of the budget stage is not to build a cheap PC. It is to spend the minimum sensible amount required to enter the correct platform.
\nA Ryzen 5 9600X works well as a transitional part: 6 cores / 12 threads, Zen 5, AM5, DDR5 and PCIe 5.0.
\nIt does not have to be the final CPU. It has to make the platform migration viable without degrading the experience while the rest of the plan is funded.
\nA well-chosen B850 can stay for the whole route. Check:
\nBuying a minimal motherboard only to replace it later destroys much of the value of a progressive migration.
\nFor development with WSL, Docker, browsers, IDEs, agents and local services, 2×32 GB is a more durable starting point than 2×16 GB.
\nOn a four-DIMM motherboard, it also leaves two DIMM slots free. Filling all four DIMM slots can reduce supported memory clocks and make stability more difficult, so “buy two now and add two matching sticks later” is not always the cleanest strategy.
\nDDR5-6000 with EXPO and reasonable timings is a useful Ryzen reference point, but EXPO is memory overclocking, not a guaranteed processor memory speed. Validate the exact kit against CPU, board and QVL, then test the chosen capacity and module count. AMD EXPO
\nThis stage is deliberately unusual: it may not require a different CPU at all.
\nIf the entry CPU still handles the workload, money may create more value in storage, cooling, backup capacity, faster networking, a UPS, ergonomics, or simply staying reserved for the final jump.
\nAn eight-core Ryzen 7 can be an excellent purchase when the machine will remain mid-range for years. If the destination is already defined as a high-end Ryzen 9, buying a Ryzen 7 only to use it for a few months creates an unnecessary rung in the ladder.
\n\n\nMid-range is a state of system maturity, not an obligation to buy an intermediate CPU.
\n
For a hybrid workstation that combines development, heavy multitasking and gaming, the Ryzen 9 X3D family is an interesting destination.
\nThe Ryzen 9 9950X3D combines 16 cores / 32 threads with 3D V-Cache. The Ryzen 9 9950X3D2 Dual Edition keeps 16/32 and extends the 3D V-Cache approach across both CCDs.
\nAMD specifies a 200 W TDP for the X3D2, versus 170 W for the 9950X3D, and recommends liquid cooling for optimal performance. If that is the destination, size the VRM, cooler and PSU for that model from the start; sharing a socket does not guarantee equal thermal headroom. 9950X3D2 Dual Edition · 9950X3D
\nThat does not automatically make the X3D2 the right purchase. It only makes sense when the workload and budget can use what it provides.
\nFor gaming-first systems, a Ryzen 7 X3D can be more rational. For compilation, virtualization, creation, heavy multitasking and many concurrent processes, 16 cores can deliver real value.
\nDo not choose a chipset for prestige.
\nB850 can be enough when you need one GPU, several NVMe drives, solid USB and a robust platform.
\nX870E starts to justify its cost when the design truly needs more connectivity and PCIe resources, multiple high-speed devices, USB4 or expansion options that will actually be used.
\nUSB4 is standard on X870E and optional on B850: the chipset name alone does not tell you which ports a particular board provides. Compare its manual and lane sharing as slots are populated. AM5 chipsets
\nThe right question is not “which one is more high-end?”, but:
\n\n\nWhich X870E capability will this workstation actually use that B850 cannot provide?
\n
If the answer is “none”, the budget probably has a better destination.
\nAssume an AM4 machine with an eight-core Ryzen 7, X570, 32 GB DDR4, RTX 30-series GPU, a fast PCIe 4.0 NVMe drive and a good-quality 850 W PSU.
\n| Part | \nDecision | \n
|---|---|
| AM4 CPU | \ndoes not migrate | \n
| X570 | \ndoes not migrate | \n
| DDR4 | \ndoes not migrate | \n
| RTX 30-series | \nmigrate | \n
| PCIe 4.0 NVMe | \nmigrate | \n
| 850 W PSU | \nmigrate if it passes review | \n
| case | \nmigrate if clearances work | \n
| cooler | \nvalidate mounting and capacity | \n
The first AM5 spend can then concentrate on CPU + motherboard + DDR5 + cooling if necessary, rather than financing a completely new PC.
\nDo not tie the plan to one store or one country. For each stage, quote parts across three markets and compare total acquisition cost.
\n| Channel | \nWhere it may stand out | \nWhat to validate | \n
|---|---|---|
| Argentina | \nimmediate availability, installments, simpler returns and local warranty | \ncash vs financed price, seller reputation and warranty | \n
| Amazon | \nnew hardware, broad catalog and occasional strong discounts | \nshipping to Argentina, estimated charges, seller, warranty and international returns | \n
| eBay | \ndeals, older generations, open-box and used parts | \nactual condition, reputation, photos, returns, shipping, charges and warranty risk | \n
For an international purchase, use:
\nlanded cost =\n component price\n+ shipping\n+ applicable import taxes / charges\n+ payment and currency-conversion costs\n+ any logistics handlingCustoms rules, allowances, taxes and courier schemes can change. Recalculate them using current conditions before completing an international purchase.
\nAs an evaluation rule, not a mandate:
\nOn eBay, CPUs, RAM and open-box or used hardware can be attractive, but a production workstation should not trade a small saving for uncertain provenance. For used motherboards, GPUs and storage, demand especially strong evidence from the seller.
\n| Criterion | \nArgentina | \nAmazon | \neBay | \n
|---|---|---|---|
| Final landed price | \ncalculate | \ncalculate | \ncalculate | \n
| Delivery time | \ncompare | \ncompare | \ncompare | \n
| Usable warranty | \nvalidate | \nvalidate | \nvalidate | \n
| Practical returns | \nvalidate | \nvalidate | \nvalidate | \n
| New / open-box / used | \nconfirm | \nconfirm | \nconfirm | \n
| Logistics risk | \nestimate | \nestimate | \nestimate | \n
| Savings vs best alternative | \ncalculate | \ncalculate | \ncalculate | \n
The winning option is not necessarily the cheapest one. It is the option whose savings are large enough to compensate for time, warranty and risk.
\nBefore paying:
\n\n\nWill this part remain in the final machine, or does it solve a measured bottleneck for long enough to justify being temporary?
\n
If neither is true, it probably should not be purchased.
\nCURRENT SETUP\n\nCPU:\nMotherboard:\nRAM:\nGPU:\nPSU (exact model + age):\nCooler:\nCase:\nNVMe/SATA:\nPCIe cards:\nCritical USB peripherals:\nOperating system:\nWSL / VMs / Docker:\nTypical workload:\nGaming (resolution / Hz):\nPeak RAM:\nPeak CPU:\nPeak VRAM:\nTemperatures:\nProblem I want to solve:\nBudget per stage:\nDesired final destination:With this information, each component can be classified as MIGRATE / REPLACE / VALIDATE / BUY LATER before designing the three stages.
\nA good upgrade route does not maximize the performance of the next receipt. It maximizes how many purchases still make sense when the machine reaches its final form.
\nAM5 is particularly useful for this strategy because it lets you separate the platform migration from the jump to the definitive CPU. The budget setup stops being a mediocre destination and becomes the first functional version of a workstation that is still growing.
\n\n\nEditorial validity: October 12, 2026. OpenDesign evolves quickly; check adapters, catalog and requirements in the official documentation before setting them as policy.
\n
Coding agents learned to build interfaces before they learned to sustain a visual identity. They can turn a brief into HTML, CSS and working components, but they still tend to design each run as if it were the first: they invent a palette, change the type scale, alter the spacing and end up back at the same generic dashboard with floating cards.
\nOpenDesign starts from a more interesting thesis than “AI designs now”: the capability already exists, but it lacks a persistent visual direction and a production method.
\nIt does not introduce a new model. It installs as a layer around the agents we already use —Codex, Claude Code, OpenCode, Cursor, Gemini CLI, Hermes and others— and turns them into the engines of a local design workspace.
\nIn a traditional prompt, product and aesthetics usually get mixed up:
\n\n\nMake a modern, elegant, dark dashboard, with metrics, filters and a premium style.
\n
The description seems sufficient until you need a second screen, a presentation or an email with the same brand. Then the drift appears: each agent interprets “modern” differently.
\nOpenDesign splits the process into pieces:
\n| Piece | \nResponsibility | \n
|---|---|
| Brief | \nGoal, audience and content | \n
| Skill | \nWorking method and production rules | \n
| Template | \nType and structure of the artifact | \n
DESIGN.md | \nThe visual identity to preserve | \n
| Agent | \nReasoning and execution | \n
The combination keeps the visual language constant while the artifact changes. The same system can steer a landing page, a dashboard, a mobile prototype or a deck without describing the brand from scratch again.
\nDESIGN.md as a visual contractThe most valuable piece of the approach is DESIGN.md: a file that encodes decisions about color, typography, hierarchy, composition, spacing, surfaces, components and constraints.
It is not just a collection of tokens. It can express judgment:
\nOpenDesign can extract that system from screenshots, Figma, a URL or a repository and store it next to the project. From then on, the direction no longer lives only in the memory of a conversation or in a person’s eye.
\nThat file can be versioned, reviewed and used with different agents. Swapping Codex for Claude Code should not require rebuilding the identity; neither should swapping a landing page for a presentation.
\nThe proposed flow is:
\nbrief → template → direction → DESIGN.md → artifact → handoff → memoryThe agent receives the visual system and relevant instructions. A CLI with filesystem tools writes project files; a BYOK/API run without those tools returns an artifact block for preview. These are not equivalent editing paths. Execution contract. The result can continue as code or be exported, depending on the format, to HTML, ZIP, PDF, PPTX or video.
\nThis changes the unit of value. It is no longer only about generating an attractive screen, but about building a process capable of producing a coherent family of artifacts.
\nOpenDesign does not replace the agent that implements. Nor does it automatically replace Figma or a designer.
\nIts role is closer to a shared creative director’s:
\nThe model still solves and writes. OpenDesign shapes the ground on which it makes those decisions.
\nThis distinction matters because agentic design does not improve only by buying a bigger model. It also improves by reducing the number of visual decisions the model has to improvise.
\nOpenDesign is closer to an agent-driven visual IDE than to a traditional collaborative canvas.
\n| OpenDesign favors | \nFigma favors | \n
|---|---|
| Generation from intent | \nDirect visual manipulation | \n
| Artifacts born as code | \nFreeform design on a canvas | \n
| Systems portable across agents | \nMature component libraries | \n
| Automation and repetition | \nPrecise comments and redlines | \n
| Direct handoff to engineering | \nMulti-person visual collaboration | \n
The comparison describes workflow emphasis, not exclusive capabilities: OpenDesign also documents comments and team workspaces. Its FAQ says there is no Figma export, so do not assume a native round-trip. Current scope.
\nThere is no need to pick one as an absolute replacement for the other. A team can explore and produce in OpenDesign, review or refine in Figma when the kind of work calls for it and bring the confirmed decisions back into the portable system.
\nIn an environment where different agents play different roles, DESIGN.md works as a shared policy. The coordinator can define the direction; a worker produces the first artifact; another reviews accessibility; another integrates it into the product. They all read the same visual contract.
This lets you separate responsibilities:
\nOrca or cockpit → coordinates sessions and projects\nCodex / Claude → reason and implement\nOpenDesign → keeps visual direction and methods\nGitHub → versions the result\nFigma → enables manual review when needed\nHosting → publishes the artifactOpenDesign does not need to take over the whole factory to be useful. It can come in as a specialty, just like a security agent, a browser or a testing tool.
\nThe project is ambitious: it combines a desktop app, a local daemon, adapters for many CLIs, skills, plugins, MCP, multimedia generation and previews. Each integration adds value, but also failure surface.
\nAlso, a huge catalog does not guarantee uniform quality. Community skills and plugins should be treated as third-party code and instructions, especially when the agent has access to the filesystem and the terminal.
\nOpen source does not mean zero cost either. The app can be free, but every generation consumes the quota or credits of the selected agent and provider.
\nOpenDesign deserves attention because it goes after the exact point where assisted development usually loses quality: inconsistency between runs.
\nModels already know how to produce interfaces. The hard part is teaching them which decisions they should not make again, which identity they must preserve and how to transfer that judgment to another agent and another format.
\nBy turning visual direction into versionable files, OpenDesign moves design from the ephemeral prompt into the project’s infrastructure. That idea matters more than any template in its catalog.
\n\n\nEditorial validity: October 12, 2026. Authentication mechanisms, models and limits depend on each provider and can change.
\n
“Local-first” sounds like a single computer. On Windows with WSL, however, one computer contains two environments that share resources but not necessarily executables, credentials or sessions.
\nThe OpenDesign app can live on Windows while Codex, Claude Code, OpenCode and the repositories live inside Ubuntu. On screen everything looks local; from the daemon’s point of view they are different worlds.
\nThat boundary defines much more than the installation. It defines who runs the model, where credentials are stored and which quota each generation counts against.
\nOpenDesign can reach a model through three conceptual routes:
\n| Route | \nAuthentication | \nSpend | \n
|---|---|---|
| Local CLI | \nInstalled agent’s authentication | \nPlan quota or API billing, depending on that authentication | \n
| BYOK / custom provider | \nAPI key | \nThe provider’s API account or balance | \n
| OpenDesign Cloud | \nOpenDesign account | \nCredits included or purchased there | \n
If OpenDesign launches a Codex CLI authenticated with ChatGPT, the work is deducted from the Codex quota. If it launches Claude Code authenticated with Pro or Max, it consumes that plan. If it gets a key in the providers panel, it is no longer using the CLI’s session: it is making API calls.
\nThe interface does not change this rule. The actual path the request takes decides it.
\nA daemon started by a Windows app inspects the Windows environment. It does not necessarily see:
\nPATH;.bashrc or systemd services.That is why having codex, claude or opencode working from Ubuntu does not guarantee OpenDesign Desktop will list them as Local CLI.
The most direct fix that keeps the native app is duplicating the CLIs on Windows and authenticating them there. The installations stay separate, even though they consume the same plan quota.
\nOpenDesign Desktop on Windows\n ↓\nNative Codex / Claude Code\n ↓\nChatGPT and Claude quotasIf the agents already live in WSL, the official WSL2 guide recommends running OpenDesign in that same environment. CLI, daemon, modules and credentials then align. The interface can open in the Windows browser. Also check which executable od resolves to: Linux includes an unrelated system utility with that name.
Windows browser\n ↓\nOpenDesign daemon in WSL\n ↓\nWSL CLIs and repositoriesThere is a third option: expose an OpenAI-compatible proxy in WSL and configure it as a custom provider.
\nOpenDesign on Windows\n ↓\nLocal proxy on 127.0.0.1\n ↓\nExternal providerWindows–WSL connectivity and daemon SSRF defenses also matter: OpenDesign blocks private/internal endpoints by default. If that protection rejects the destination, review the documented exact-host allowlist rather than opening broad ranges. This deployment condition needs testing. Proxy security.
\nThis path does not automatically reuse the Codex or Claude quota. OpenDesign thinks it is talking to an API; the proxy decides which provider and credential to use behind it.
\nThe pattern can adapt protocols and sessions, but an API does not authorize every use. OpenCode Go is intended for coding-agent traffic: it requires an identifiable client and stable session. A proxy does not make an arbitrary workload compatible; check the client and each model’s endpoint, which may use Responses, Chat Completions or Messages.
\nA proxy is not necessarily a hack. It can become a control boundary:
\nBut every added responsibility also turns the proxy into infrastructure someone has to maintain.
\nA compatible endpoint does not guarantee a correctly identified conversation. OpenCode Go asks for a stable session per conversation, through native client information or the x-opencode-session header.
The proxy must avoid two extremes:
\nThe right unit is usually an OpenDesign thread or project:
\nx-opencode-session = hash(project_id + conversation_id)The derivation must not include prompts, secrets or the API key.
\nWhen OpenDesign requires filling in an API key field for a custom provider, there are two possible designs.
\nOpenDesign stores the provider key and sends it to the proxy, which forwards it.
\nIt is simple, but the credential is stored and travels through more components.
\nOpenDesign uses a random local token. The proxy validates it and fetches the real key from its own protected environment.
\nOpenDesign → local token\nProxy → validates the local token\nExternal provider → receives the real keyThis separation limits the impact of an export, an accidental log or a client-side failure. For a stable installation it is the preferable option.
\nA bridge like this should meet at least these conditions:
\nAuthorization, full bodies or sensitive variables;User-Agent;Binding it to 0.0.0.0 turns a local bridge into a service reachable from the network. That decision demands authentication, a firewall and a different review.
The rule for understanding spend is to follow the whole request:
\nWho ultimately received the authenticated call?The model label in the interface can be misleading. An OpenAI model served by OpenCode Go does not consume the ChatGPT plan; it consumes the allowance of the provider that served the request.
\nTo keep existing sessions and separate spend, one possible layout is:
\n| Path | \nUse | \n
|---|---|
| OpenDesign → Codex on Windows | \nWork deducted from the Codex plan | \n
| OpenDesign → Claude Code on Windows | \nWork deducted from the Claude plan | \n
| OpenDesign → WSL proxy → OpenCode Go | \nCheap models under Go’s limits | \n
| Orca → WSL CLIs | \nExisting development and coordination | \n
Duplicating CLIs is not elegant, but it keeps the boundaries clear. Moving the whole daemon to WSL reduces duplication, although it gives up part of the native app’s convenience.
\nLocal integration does not depend only on two processes living on the same computer. It depends on them sharing the right environment.
\nInstalling the CLIs on Windows is the simplest route for OpenDesign Desktop to consume plan quotas. Running the daemon in WSL is the most coherent route for reusing existing installations. A proxy is the most flexible route when the provider offers an API and we need to control sessions, credentials or compatibility.
\nNo option always wins. The right decision comes from choosing what we want to preserve: desktop convenience, existing sessions, traffic control or credential isolation.
\n\n\nProduct reference reviewed October 12, 2026: Hermes Agent by Nous Research. The workflows and permissions here are design decisions, not automatic product guarantees.
\n
Hermes is useful when the agent’s value is not only in talking to a technical person, but in being available inside an operational loop: taking questions from a shared channel, querying connected systems and sending alerts before someone remembers to look at a dashboard.
\nIn this workflow it complements Codex, Claude Code or OpenCode. Hermes also offers a CLI and development tools; the focus here is its messaging gateway, which brings those capabilities closer to the team and its channels.
\nMany internal capabilities end up concentrated in whoever has CRM access, knows a query or pays for a tool seat. Hermes lets you wrap those capabilities in a more accessible conversational interface:
\nThe important leap is going from an assistant that answers when called to an agent that is part of the work system.
\nThe team asks from a channel it already uses, without learning a new interface or opening a technical session. This does not remove access control: it requires allowlists, clear identities and different capabilities per user or channel.
\nA passive event in a queue or a Signals system becomes an actionable alert. The automation has to tell operational information apart from sensitive notices and choose the right channel for each.
\nHermes can use connected tools to query the CRM, databases, documentation or services. The value is not in adding every possible MCP, but in choosing the minimum that solves the case and granting the least privilege needed.
\nInstalling Hermes does not define:
\nThose decisions are part of the product. An agent reachable by more people amplifies usefulness, but also risk surface and spend.
\nThe agent should bring capabilities closer to the team without bringing unnecessary authority along.
\nA sales question may need read access to the CRM. It does not need to edit records, reach production over SSH or know credentials. The experience is designed from that limit, not from everything that could technically be connected.
\n", "headings": [ { "label": "The core idea", "depth": 2, "id": "the-core-idea" }, { "label": "What problem it solves", "depth": 2, "id": "what-problem-it-solves" }, { "label": "Where it adds value", "depth": 2, "id": "where-it-adds-value" }, { "label": "Distributed access", "depth": 3, "id": "distributed-access" }, { "label": "Proactivity", "depth": 3, "id": "proactivity" }, { "label": "Integration", "depth": 3, "id": "integration" }, { "label": "What it does not solve on its own", "depth": 2, "id": "what-it-does-not-solve-on-its-own" }, { "label": "Design principle", "depth": 2, "id": "design-principle" } ], "raw": "---\nslug: hermes-agente-operativo\ntitle: Hermes as an operational agent\ntype: concept\norder: 1\nsummary: A self-hosted agent that brings queries and alerts to the channels where the team works, without turning every interaction into a technical session.\ntags: [hermes, agents, channels, mcp, automation]\nrelated: [hermes-preset-instalacion, caso-hermes-operaciones, modelos-guiados-el-entorno-es-la-politica]\narea: Hermes\nglyph: ✦\nhue: rgba(236,95,189,.24)\n---\n\n# Hermes as an operational agent\n\n> Product reference reviewed October 12, 2026: [Hermes Agent by Nous Research](https://hermes-agent.nousresearch.com/docs). The workflows and permissions here are design decisions, not automatic product guarantees.\n\n## The core idea\n\nHermes is useful when the agent’s value is not only in talking to a technical person, but in **being available inside an operational loop**: taking questions from a shared channel, querying connected systems and sending alerts before someone remembers to look at a dashboard.\n\nIn this workflow it complements Codex, Claude Code or OpenCode. Hermes also offers a CLI and development tools; the focus here is its messaging gateway, which brings those capabilities closer to the team and its channels.\n\n## What problem it solves\n\nMany internal capabilities end up concentrated in whoever has CRM access, knows a query or pays for a tool seat. Hermes lets you wrap those capabilities in a more accessible conversational interface:\n\n- questions about operational data from WhatsApp, Slack or Discord;\n- proactive notices triggered by cron or events;\n- separation between team channels and administrative notifications;\n- access to systems through MCP integrations with controlled scope;\n- continuous operation on your own or managed infrastructure.\n\nThe important leap is going from **an assistant that answers when called** to **an agent that is part of the work system**.\n\n## Where it adds value\n\n### Distributed access\n\nThe team asks from a channel it already uses, without learning a new interface or opening a technical session. This does not remove access control: it requires allowlists, clear identities and different capabilities per user or channel.\n\n### Proactivity\n\nA passive event in a queue or a Signals system becomes an actionable alert. The automation has to tell operational information apart from sensitive notices and choose the right channel for each.\n\n### Integration\n\nHermes can use connected tools to query the CRM, databases, documentation or services. The value is not in adding every possible MCP, but in choosing the minimum that solves the case and granting the least privilege needed.\n\n## What it does not solve on its own\n\nInstalling Hermes does not define:\n\n- where to host it;\n- which model to use;\n- who can talk to it;\n- which tools it can run;\n- how many subagents to launch;\n- how to handle failures and secrets.\n\nThose decisions are part of the product. An agent reachable by more people amplifies usefulness, but also risk surface and spend.\n\n## Design principle\n\n**The agent should bring capabilities closer to the team without bringing unnecessary authority along.**\n\nA sales question may need read access to the CRM. It does not need to edit records, reach production over SSH or know credentials. The experience is designed from that limit, not from everything that could technically be connected.\n", "language": "en" }, { "slug": "hermes-preset-instalacion", "title": "Hermes installation preset", "summary": "Five decisions to make before setting up Hermes without copying someone else’s infrastructure: hosting, model, channels, concurrency and integrations.", "type": "guide", "order": 2, "tags": [ "hermes", "setup", "hosting", "models", "mcp" ], "related": [ "hermes-agente-operativo", "caso-hermes-operaciones" ], "area": "Hermes", "glyph": "◇", "hue": "rgba(168,106,255,.24)", "file": "hermes-preset-instalacion.md", "html": "\n\nProduct reference reviewed October 12, 2026: Hermes Agent by Nous Research. The workflows and permissions here are design decisions, not automatic product guarantees.
\n
Setting up Hermes does not start with a command. It starts with five decisions that determine cost, security and usefulness. The preset does not prescribe a provider: it works as a guide for designing the instance to fit the context.
\nCommon options:
\nSeparate the gateway host from its tool-execution backend: Hermes documents backends such as Docker, SSH, Daytona and Modal. Choosing a serverless sandbox does not by itself solve gateway availability or require a local GPU for a remote model.
\nUseful questions:
\nReusing a VPS lowers cost, but it shares failures and resources with whatever already lives there. Capacity is measured after deploying; it is not guessed from the sales sheet.
\nYou can use a direct API, an aggregator like OpenRouter or the provider offered by the Hermes ecosystem.
\nIf it is unclear which model fits, the healthiest method is a small benchmark with real queries. Scoring accuracy and cost on the same set avoids choosing by reputation or a friendly demo.
\nThe key should be exclusive to the project. It isolates spend, telemetry, revocation and blast radius.
\nHermes can connect to WhatsApp, Telegram, Discord, Slack, Teams, Signal, email and other channels. The question is not how many it supports, but who needs access and what information they can receive.
\nSeparating channels by role keeps an administrative alert from ending up in a sales space. The same agent can talk with the team and notify the administrator, but each path needs its own policy.
\nStarting with a conservative subagent limit is an operational decision, not a loss of power. Parallelism goes up once there are real metrics for CPU, RAM, latency and cost.
\nIf the infrastructure hosts other services, the agent cannot treat all the resources as its own.
\nFor every MCP or connected tool, state:
\nA services company needed to bring operational information closer to a non-technical team and turn passive events into actionable notices. The goal was not to add another AI chat, but to reduce dependence on a single person who knew how to query each system.
\nHermes was framed as a conversational layer connected to internal tools, available from channels the team already used.
\nThe first version was installed on existing infrastructure. To keep the new service from competing uncontrollably with other workloads, a conservative concurrency limit was set and any expansion was postponed until there were real metrics.
\nAccess to the model provider was created exclusively for the project. This made it possible to compare alternatives, watch spend and revoke the integration without affecting other agents.
\nThe model was chosen with a fixed set of representative queries, scoring accuracy and cost. The comparison relied on real tasks rather than a general impression.
\nTeam queries and administrative alerts were treated as different paths. Each channel received only the information that matched its role.
\nCredentials stayed in the runtime environment. They were not copied into documentation, prompts or context files shared with the agent.
\nThe first version was considered valid once it could demonstrate three behaviors:
\nEach milestone describes observable evidence. “The agent is installed” does not count as a result.
\nThe team gained a direct way to query information and receive notices without depending on a specialized interface. At the same time, the organization kept control through minimal permissions, authorized identities and channel separation.
\n\n\n", "headings": [ { "label": "Anonymized context", "depth": 2, "id": "anonymized-context" }, { "label": "Decisions made", "depth": 2, "id": "decisions-made" }, { "label": "Reuse infrastructure with an initial limit", "depth": 3, "id": "reuse-infrastructure-with-an-initial-limit" }, { "label": "Isolate provider and spend", "depth": 3, "id": "isolate-provider-and-spend" }, { "label": "Separate audiences", "depth": 3, "id": "separate-audiences" }, { "label": "Keep secrets out of the context", "depth": 3, "id": "keep-secrets-out-of-the-context" }, { "label": "A verifiable MVP", "depth": 2, "id": "a-verifiable-mvp" }, { "label": "What we learned", "depth": 2, "id": "what-we-learned" }, { "label": "The benefit", "depth": 2, "id": "the-benefit" } ], "raw": "---\nslug: caso-hermes-operaciones\ntitle: Case study — Hermes as an operational interface\ntype: case-study\norder: 3\nsummary: A self-hosted agent brought queries and alerts into everyday channels, with scoped permissions and observable business tests.\ntags: [hermes, agents, channels, operations, case-study]\nrelated: [hermes-agente-operativo, hermes-preset-instalacion]\narea: Hermes\nglyph: ◈\nhue: rgba(87,217,232,.22)\n---\n\n# Case study — Hermes as an operational interface\n\n## Anonymized context\n\nA services company needed to bring operational information closer to a non-technical team and turn passive events into actionable notices. The goal was not to add another AI chat, but to reduce dependence on a single person who knew how to query each system.\n\nHermes was framed as a conversational layer connected to internal tools, available from channels the team already used.\n\n## Decisions made\n\n### Reuse infrastructure with an initial limit\n\nThe first version was installed on existing infrastructure. To keep the new service from competing uncontrollably with other workloads, a conservative concurrency limit was set and any expansion was postponed until there were real metrics.\n\n### Isolate provider and spend\n\nAccess to the model provider was created exclusively for the project. This made it possible to compare alternatives, watch spend and revoke the integration without affecting other agents.\n\nThe model was chosen with a fixed set of representative queries, scoring accuracy and cost. The comparison relied on real tasks rather than a general impression.\n\n### Separate audiences\n\nTeam queries and administrative alerts were treated as different paths. Each channel received only the information that matched its role.\n\n### Keep secrets out of the context\n\nCredentials stayed in the runtime environment. They were not copied into documentation, prompts or context files shared with the agent.\n\n## A verifiable MVP\n\nThe first version was considered valid once it could demonstrate three behaviors:\n\n1. An authorized user asked an operational question and got an answer consistent with the source system.\n2. A controlled event produced an alert within the expected interval.\n3. A restricted notification reached the administrative channel but not the general one.\n\nEach milestone describes observable evidence. “The agent is installed” does not count as a result.\n\n## What we learned\n\n- Reusing infrastructure works when capacity starts bounded and is measured.\n- One credential per project simplifies cost, auditing and revocation.\n- The value shows up in the full path: channel → agent → tool → answer.\n- Separating audiences matters as much as connecting channels.\n- An operational MVP needs business tests, not just technical checks.\n\n## The benefit\n\nThe team gained a direct way to query information and receive notices without depending on a specialized interface. At the same time, the organization kept control through minimal permissions, authorized identities and channel separation.\n\n> Case based on a real implementation. Names, infrastructure, metrics and internal flows have been removed.\n", "language": "en" }, { "slug": "backup-versionado-crm", "title": "From backup to a CRM function platform", "summary": "The read-only backup became the foundation of an internal platform for analyzing, reviewing and deploying CRM functions with separate authorities.", "type": "concept", "order": 1, "tags": [ "zoho-crm", "backup", "git", "deluge", "audit", "deployment" ], "related": [ "arquitectura-read-only", "mapa-procesos-verificacion", "modelos-guiados-el-entorno-es-la-politica" ], "area": "CRM versionado", "glyph": "▣", "hue": "rgba(237,195,94,.25)", "file": "backup-versionado-crm.md", "html": "Case based on a real implementation. Names, infrastructure, metrics and internal flows have been removed.
\n
\n\nUpdated on October 12, 2026 with the internal evolution known as V2, documented in the project as the multiuser deployment stage. Implemented capabilities and pending tests are distinguished below.
\n
The Deluge code behind the automations lives inside Zoho CRM. The current interface provides a Revisions tab with the latest 30 versions; for Deluge, each save creates a revision. That bounded history does not replace an external repository with diffs, analysis and its own retention policy. Function management.
\nThe starting point was downloading the code and metadata of every function, generating a deterministic tree and creating a commit only when something actually changed. That layer remains read-only.
\nThe next stage added a path for preparing changes, reviewing them and publishing with a different authority. The repository became a small internal function-management platform: a CLI, contracts, Git controls and an explicit deployment path. The CLI and GitHub review organize who can propose, who can publish and what evidence each transition requires.
\ngit log, diffs and blame on previously opaque functions.Daily scheduler\n → Node.js sync\n → Zoho CRM API in read mode\n → generated, normalized tree\n → commit only on change\n → private Git repository\n → result webhook\n → alert only when there is a problemThe synchronization credential only has ZohoCRM.settings.functions.READ. The restriction lives below the code: even if the process tried to update a function, it would have no authority to do so.
The snapshot turned hunches into an inventory. The first audit found a significant surface of functions exposed over REST, test automations still active, undocumented functions and literal credentials inside the code.
\nThe exact figures are not needed to reuse the method. The important lesson is that these risks were not observable from a casual look at the interface: they appeared when downloading, normalizing and classifying the full tree.
\nThe snapshot in this case did not verify every association, so the report could only flag candidates, not claim that a function was unused. Zoho’s current interface does document associations, references and dependencies in Glance. Consulting them adds evidence; it does not show that the backup client downloads them or rule out external invocations. Function management.
\nA backup that changes every day without real changes is noise. For Git to tell a useful story:
\napi_name is not unique.The CLI implements creation or updating of one Deluge function at a time. For an existing function, the multiuser path starts from a baseline obtained from production. The change is prepared outside the generated tree, versioned as a proposal and reviewed before an authorized owner deploys it.
\nProduction → change baseline → proposal in cambios/\n → pull request → owner review → merge\n → preflight checks → explicit deployment\n → download again and compareThis separation avoids two different mistakes: editing a backup as though it were code ready to publish, and giving production permissions to everyone who needs to analyze it. A contributor can prepare a proposal with read access; publication belongs to another role.
\nThe documented normal path requires checking function identity, file provenance and whether production changed since the proposal's baseline. Downloading again lets the tool compare what the CRM received with what was sent, using exact or normalized comparison. This is not a test of semantic equivalence. Legacy options allow work outside the normal path, so these guarantees depend on following it with its baseline and full controls. Every barrier has a cost: maintaining metadata, resolving conflicts and rejecting changes that previously could have been pasted directly into the interface. That cost buys reproducible review.
\nThe internal documentation reviewed describes the implementation of this path and records tests of its controls with writes disabled. It also leaves the first real deployment from the changes directory and contributor onboarding pending. This is therefore an implemented capability with incomplete operational validation, rather than a production workflow already proven end to end.
\nThe write is not an atomic transaction with automatic rollback: if the subsequent comparison fails, the tool reports the problem and requires inspection. Reading back checks content; it does not by itself test business-flow behavior, associations or a function's external effects. Those outcomes need specific tests and observation after the change.
\nIt fits when several people or agents need to analyze and propose changes to sensitive automations while production authority must remain bounded. A small team making occasional changes can start with backup and manual review: adding a deployment path before defining owners and checks only adds another way to make mistakes.
\nThe prerequisite for going further is sustaining both halves: a reliable picture of production and an explicit publication path that does not inherit analysis permissions. The read-only architecture explains that separation; the process map shows how to turn a finding into verifiable work.
\nThe backup had already made it possible to review changes, audit risks and analyze state without distributing production credentials. The next stage uses that foundation to organize the path from a finding to publication. The observed benefit of reading is preserved; closing the full deployment loop remains subject to the pending tests.
\n", "headings": [ { "label": "The problem", "depth": 2, "id": "the-problem" }, { "label": "Four results in a single run", "depth": 2, "id": "four-results-in-a-single-run" }, { "label": "The observation layer", "depth": 2, "id": "the-observation-layer" }, { "label": "What it made visible", "depth": 2, "id": "what-it-made-visible" }, { "label": "The value rule", "depth": 2, "id": "the-value-rule" }, { "label": "From inventory to a reviewable change", "depth": 2, "id": "from-inventory-to-a-reviewable-change" }, { "label": "What is demonstrated and what remains open", "depth": 2, "id": "what-is-demonstrated-and-what-remains-open" }, { "label": "When this design makes sense", "depth": 2, "id": "when-this-design-makes-sense" }, { "label": "The benefit", "depth": 2, "id": "the-benefit" } ], "raw": "---\nslug: backup-versionado-crm\ntitle: From backup to a CRM function platform\ntype: concept\norder: 1\nsummary: The read-only backup became the foundation of an internal platform for analyzing, reviewing and deploying CRM functions with separate authorities.\ntags: [zoho-crm, backup, git, deluge, audit, deployment]\nrelated: [arquitectura-read-only, mapa-procesos-verificacion, modelos-guiados-el-entorno-es-la-politica]\narea: CRM versionado\nglyph: ▣\nhue: rgba(237,195,94,.25)\n---\n\n# From backup to a CRM function platform\n\n> Updated on October 12, 2026 with the internal evolution known as V2, documented in the project as the multiuser deployment stage. Implemented capabilities and pending tests are distinguished below.\n\n## The problem\n\nThe Deluge code behind the automations lives inside Zoho CRM. The current interface provides a Revisions tab with the latest 30 versions; for Deluge, each save creates a revision. That bounded history does not replace an external repository with diffs, analysis and its own retention policy. [Function management](https://www.zoho.com/crm/developer/docs/functions/management.html).\n\nThe starting point was downloading the code and metadata of every function, generating a deterministic tree and creating a commit only when something actually changed. That layer remains read-only.\n\nThe next stage added a path for preparing changes, reviewing them and publishing with a different authority. The repository became a small internal function-management platform: a CLI, contracts, Git controls and an explicit deployment path. The CLI and GitHub review organize who can propose, who can publish and what evidence each transition requires.\n\n## Four results in a single run\n\n1. **Backup:** complete source code outside the CRM.\n2. **History:** `git log`, diffs and blame on previously opaque functions.\n3. **Audit:** regenerated reports showing REST surface, test functions, hygiene and literal secrets.\n4. **Map:** grouping by business flow so a branch can be analyzed without walking the whole tree by hand.\n\n## The observation layer\n\n```text\nDaily scheduler\n → Node.js sync\n → Zoho CRM API in read mode\n → generated, normalized tree\n → commit only on change\n → private Git repository\n → result webhook\n → alert only when there is a problem\n```\n\nThe synchronization credential only has `ZohoCRM.settings.functions.READ`. The restriction lives below the code: even if the process tried to update a function, it would have no authority to do so.\n\n## What it made visible\n\nThe snapshot turned hunches into an inventory. The first audit found a significant surface of functions exposed over REST, test automations still active, undocumented functions and literal credentials inside the code.\n\nThe exact figures are not needed to reuse the method. The important lesson is that these risks were not observable from a casual look at the interface: they appeared when downloading, normalizing and classifying the full tree.\n\nThe snapshot in this case did not verify every association, so the report could only flag candidates, not claim that a function was unused. Zoho’s current interface does document associations, references and dependencies in Glance. Consulting them adds evidence; it does not show that the backup client downloads them or rule out external invocations. [Function management](https://www.zoho.com/crm/developer/docs/functions/management.html).\n\n## The value rule\n\nA backup that changes every day without real changes is noise. For Git to tell a useful story:\n\n- the JSON sorts its keys;\n- files normalize line endings;\n- reports do not include generation timestamps;\n- pruning only runs if every download finished;\n- the category is part of the path because `api_name` is not unique.\n\n## From inventory to a reviewable change\n\nThe CLI implements creation or updating of one Deluge function at a time. For an existing function, the multiuser path starts from a baseline obtained from production. The change is prepared outside the generated tree, versioned as a proposal and reviewed before an authorized owner deploys it.\n\n```text\nProduction → change baseline → proposal in cambios/\n → pull request → owner review → merge\n → preflight checks → explicit deployment\n → download again and compare\n```\n\nThis separation avoids two different mistakes: editing a backup as though it were code ready to publish, and giving production permissions to everyone who needs to analyze it. A contributor can prepare a proposal with read access; publication belongs to another role.\n\nThe documented normal path requires checking function identity, file provenance and whether production changed since the proposal's baseline. Downloading again lets the tool compare what the CRM received with what was sent, using exact or normalized comparison. This is not a test of semantic equivalence. Legacy options allow work outside the normal path, so these guarantees depend on following it with its baseline and full controls. Every barrier has a cost: maintaining metadata, resolving conflicts and rejecting changes that previously could have been pasted directly into the interface. That cost buys reproducible review.\n\n## What is demonstrated and what remains open\n\nThe internal documentation reviewed describes the implementation of this path and records tests of its controls with writes disabled. It also leaves the first real deployment from the changes directory and contributor onboarding pending. This is therefore an implemented capability with incomplete operational validation, rather than a production workflow already proven end to end.\n\nThe write is not an atomic transaction with automatic rollback: if the subsequent comparison fails, the tool reports the problem and requires inspection. Reading back checks content; it does not by itself test business-flow behavior, associations or a function's external effects. Those outcomes need specific tests and observation after the change.\n\n## When this design makes sense\n\nIt fits when several people or agents need to analyze and propose changes to sensitive automations while production authority must remain bounded. A small team making occasional changes can start with backup and manual review: adding a deployment path before defining owners and checks only adds another way to make mistakes.\n\nThe prerequisite for going further is sustaining both halves: a reliable picture of production and an explicit publication path that does not inherit analysis permissions. The [read-only architecture](/en/entrada/arquitectura-read-only) explains that separation; the [process map](/en/entrada/mapa-procesos-verificacion) shows how to turn a finding into verifiable work.\n\n## The benefit\n\nThe backup had already made it possible to review changes, audit risks and analyze state without distributing production credentials. The next stage uses that foundation to organize the path from a finding to publication. The observed benefit of reading is preserved; closing the full deployment loop remains subject to the pending tests.\n", "language": "en" }, { "slug": "arquitectura-read-only", "title": "Read-only as an architectural decision", "summary": "Keep backup and analysis without production authority while a separate path allows reviewed, verifiable changes to be deployed.", "type": "guide", "order": 2, "tags": [ "read-only", "permissions", "zoho", "security", "snapshots" ], "related": [ "backup-versionado-crm", "mapa-procesos-verificacion", "modelos-guiados-el-entorno-es-la-politica" ], "area": "CRM versionado", "glyph": "⌁", "hue": "rgba(87,217,232,.22)", "file": "arquitectura-read-only.md", "html": "\n\nUpdated on October 12, 2026. The initial stage was entirely read-only; the multiuser evolution preserves that boundary for observation and adds a controlled write path.
\n
For Zoho CRM Deluge functions, creating or updating through the API publishes the change immediately. API V8 distinguishes this behavior from Java, Node.js and Python, which support drafts and separate publication. A PUT against Deluge in production can affect active code: do not generalize the draft protection of other runtimes. Functions in V8.
That is why reading was not treated as a convention of the script, but as a property of the system. The project evolution changes the scope of that statement: it describes synchronization and analysis, while deployment has its own credentials, commands and conditions.
\nThe read token only uses ZohoCRM.settings.functions.READ. It has no Create, Update, Publish or Delete. The credential rejects a mutation even if the code attempts one.
The original client only implemented reading. The deployment stage incorporates mutating operations in an explicit path disabled by default. Describing the entire project as exclusively GET would now be incorrect: what must be preserved is that the observation task has no authority to publish.
functions/ is a snapshot of the CRM and is not edited by hand. Proposals live in cambios/, with their baseline and metadata for review. The separation makes it clear what was observed and what is intended to change; a subsequent synchronization reflects production state again.
The repository preserves snapshots and now also organizes proposals through pull requests and review owners. Merge and deployment are different steps: having a change in Git does not mean it has been published or that its result has been verified.
\nThe contributor works with read permissions. The deployment owner needs a credential authorized by CRM scopes and profile, as well as explicitly enabling writes and passing additional checks. The CLI flag prevents accidents; it is not a permission boundary by itself. A person allowed to edit in the CRM interface can still do so outside this convention. In the documented normal path for reviewed changes:
\napi_name does not authorize choosing an arbitrary target;main aligned with origin/main;The CLI also retains an explicit option for files outside main; if the baseline header is missing, that path can continue with a warning and without drift protection. Having controls in the repository is therefore not enough: the team must require the reviewed path and treat exceptions as higher-risk decisions.
If production changed in the meantime within the protected path, the proposal must be reviewed again against a current baseline. The comparison detects some code drift before writing; it is not an atomic lock against concurrent changes and does not guarantee that data, connections or associations remained unchanged.
\nThe normalized comparison removes whitespace and parentheses: it can treat different texts as equal and is not a semantic test. If post-write verification fails, the error is reported; there is no automatic rollback. The operation may already have published, and a notification failure does not undo it either.
\nThese controls complement human review. They do not turn Deluge into a runtime with drafts: the risk of immediate publication remains relevant. The documentation records tests without writes and leaves the first real deployment through this path pending; a tested guardrail must not be presented as a complete deployment test.
\napi_name; the name alone can collide.Source code may contain literal credentials. Before the first push, scan the tree and decide on each finding:
\nA cloud provider credential may be detected and revoked automatically when pushed. Excluding it avoids that breakage, but creates explicit debt: the function stops having history.
\nA normal run with no changes creates no commit and sends no notification. Silence is healthy only if there is a separate control that notices when the signal stops arriving.
\nThe dead-man’s switch lives outside the scheduler and distinguishes the last run from the last success. It should alert if either signal grows stale: a series of errors must not keep the health signal fresh. If it shared a process with the sync, they would die together and the silence would be ambiguous.
\nAuthority should follow the task: observe with read permissions, propose in a separate space, and publish only through an explicit, reviewed and verifiable path.
\n", "headings": [ { "label": "Why promising not to write is not enough", "depth": 2, "id": "why-promising-not-to-write-is-not-enough" }, { "label": "The barriers", "depth": 2, "id": "the-barriers" }, { "label": "Minimal scope", "depth": 3, "id": "minimal-scope" }, { "label": "Separate reading and writing", "depth": 3, "id": "separate-reading-and-writing" }, { "label": "A generated tree", "depth": 3, "id": "a-generated-tree" }, { "label": "Git as review and provenance", "depth": 3, "id": "git-as-review-and-provenance" }, { "label": "Deployment authority is not inherited", "depth": 2, "id": "deployment-authority-is-not-inherited" }, { "label": "Decisions that prevent fake backups", "depth": 2, "id": "decisions-that-prevent-fake-backups" }, { "label": "The awkward case of secrets", "depth": 2, "id": "the-awkward-case-of-secrets" }, { "label": "Quiet operation, active monitoring", "depth": 2, "id": "quiet-operation-active-monitoring" }, { "label": "Reusable principle", "depth": 2, "id": "reusable-principle" } ], "raw": "---\nslug: arquitectura-read-only\ntitle: Read-only as an architectural decision\ntype: guide\norder: 2\nsummary: Keep backup and analysis without production authority while a separate path allows reviewed, verifiable changes to be deployed.\ntags: [read-only, permissions, zoho, security, snapshots]\nrelated: [backup-versionado-crm, mapa-procesos-verificacion, modelos-guiados-el-entorno-es-la-politica]\narea: CRM versionado\nglyph: ⌁\nhue: rgba(87,217,232,.22)\n---\n\n# Read-only as an architectural decision\n\n> Updated on October 12, 2026. The initial stage was entirely read-only; the multiuser evolution preserves that boundary for observation and adds a controlled write path.\n\n## Why promising not to write is not enough\n\nFor Zoho CRM Deluge functions, creating or updating through the API publishes the change immediately. API V8 distinguishes this behavior from Java, Node.js and Python, which support drafts and separate publication. A `PUT` against Deluge in production can affect active code: do not generalize the draft protection of other runtimes. [Functions in V8](https://www.zoho.com/crm/developer/docs/api/v8/whats-new.html).\n\nThat is why reading was not treated as a convention of the script, but as a property of the system. The project evolution changes the scope of that statement: it describes synchronization and analysis, while deployment has its own credentials, commands and conditions.\n\n## The barriers\n\n### Minimal scope\n\nThe read token only uses `ZohoCRM.settings.functions.READ`. It has no Create, Update, Publish or Delete. The credential rejects a mutation even if the code attempts one.\n\n### Separate reading and writing\n\nThe original client only implemented reading. The deployment stage incorporates mutating operations in an explicit path disabled by default. Describing the entire project as exclusively `GET` would now be incorrect: what must be preserved is that the observation task has no authority to publish.\n\n### A generated tree\n\n`functions/` is a snapshot of the CRM and is not edited by hand. Proposals live in `cambios/`, with their baseline and metadata for review. The separation makes it clear what was observed and what is intended to change; a subsequent synchronization reflects production state again.\n\n### Git as review and provenance\n\nThe repository preserves snapshots and now also organizes proposals through pull requests and review owners. Merge and deployment are different steps: having a change in Git does not mean it has been published or that its result has been verified.\n\n## Deployment authority is not inherited\n\nThe contributor works with read permissions. The deployment owner needs a credential authorized by CRM scopes and profile, as well as explicitly enabling writes and passing additional checks. The CLI flag prevents accidents; it is not a permission boundary by itself. A person allowed to edit in the CRM interface can still do so outside this convention. In the documented normal path for reviewed changes:\n\n- the function must resolve unambiguously; a colliding `api_name` does not authorize choosing an arbitrary target;\n- the file to publish must be tracked, locally unchanged and on `main` aligned with `origin/main`;\n- a hash comparison of normalized code detects production changes relative to the baseline used to prepare the proposal;\n- after publishing, the code is downloaded and compared with what was sent, either exactly or with normalization.\n\nThe CLI also retains an explicit option for files outside `main`; if the baseline header is missing, that path can continue with a warning and without drift protection. Having controls in the repository is therefore not enough: the team must require the reviewed path and treat exceptions as higher-risk decisions.\n\nIf production changed in the meantime within the protected path, the proposal must be reviewed again against a current baseline. The comparison detects some code drift before writing; it is not an atomic lock against concurrent changes and does not guarantee that data, connections or associations remained unchanged.\n\nThe normalized comparison removes whitespace and parentheses: it can treat different texts as equal and is not a semantic test. If post-write verification fails, the error is reported; there is no automatic rollback. The operation may already have published, and a notification failure does not undo it either.\n\nThese controls complement human review. They do not turn Deluge into a runtime with drafts: the risk of immediate publication remains relevant. The documentation records tests without writes and leaves the first real deployment through this path pending; a tested guardrail must not be presented as a complete deployment test.\n\n## Decisions that prevent fake backups\n\n- The path includes the category and `api_name`; the name alone can collide.\n- The run aborts on a collision instead of silently overwriting.\n- Pruning is disabled if any download failed.\n- Without a readable previous snapshot, the fallback is a full download.\n- If the expected count does not match the pagination, no partial snapshot is saved.\n\n## The awkward case of secrets\n\nSource code may contain literal credentials. Before the first push, scan the tree and decide on each finding:\n\n1. rotate and remove the credential;\n2. version it in a private repository if the risk was accepted;\n3. temporarily exclude the file and document that it has no backup.\n\nA cloud provider credential may be detected and revoked automatically when pushed. Excluding it avoids that breakage, but creates explicit debt: the function stops having history.\n\n## Quiet operation, active monitoring\n\nA normal run with no changes creates no commit and sends no notification. Silence is healthy only if there is a separate control that notices when the signal stops arriving.\n\nThe dead-man’s switch lives outside the scheduler and distinguishes the last run from the last success. It should alert if either signal grows stale: a series of errors must not keep the health signal fresh. If it shared a process with the sync, they would die together and the silence would be ambiguous.\n\n## Reusable principle\n\n**Authority should follow the task: observe with read permissions, propose in a separate space, and publish only through an explicit, reviewed and verifiable path.**\n", "language": "en" }, { "slug": "mapa-procesos-verificacion", "title": "From backup to process map", "summary": "The process map enables analysis without production access; the new change path connects verifiable findings with review and controlled deployment.", "type": "case-study", "order": 3, "tags": [ "processes", "audit", "agents", "verification", "zoho-crm" ], "related": [ "backup-versionado-crm", "arquitectura-read-only", "orquestacion" ], "area": "CRM versionado", "glyph": "⌘", "hue": "rgba(168,106,255,.24)", "file": "mapa-procesos-verificacion.md", "html": "\n\nUpdated on October 12, 2026. The analysis pilot is preserved and distinguished from the subsequent multiuser deployment stage.
\n
The backup answered what code existed. It did not explain how the business was organized, which functions made up a flow or how to check that a fix had been applied.
\nThe second stage added three pieces:
\n| Piece | \nWhat it answers | \n
|---|---|
| Resource dictionary | \nWhich functions use each shared resource and what the blast radius is | \n
| Process tree | \nWhich flows exist and which functions make up each branch | \n
| Analysis contract | \nHow a branch should be analyzed and what evidence to deliver | \n
Data that changes is regenerated on every sync. The conceptual organization is expressed through rules maintained by people.
\nNo manual lists of functions are written into the documentation: they go stale the next day. A rule absorbs new functions and the report flags those that do not fit any branch.
\nThe process for a person or agent is deliberately bounded:
\n| Deliverable | \nPurpose | \n
|---|---|
manual-operativo.md | \nExplain the flow in business terms | \n
mejoras-propuestas.md | \nRank findings by consequence, anchored to file and line | \n
validar.sh | \nTurn every finding into an executable check | \n
In the original test, the agent started from computed reports rather than a blind search across more than thirteen hundred functions. That size describes the inventory at the time, not an updated count. The advantage of the method is bounded context and repeatable analysis.
\nThe analysis fixes visible defects; it does not redesign processes or propose broad migrations. On a platform where publishing is immediate, a large redesign of a flow that moves money needs another level of governance.
\nThe restriction does not live only in the prompt: every finding that gets developed must be expressible as an automated check. If it cannot be verified, it is noted as a separate idea and not presented as a ready fix.
\nWhen someone reports they fixed a finding, there is no need to pay for reasoning again to read the code. You run validar.sh against the current snapshot.
Prose goes stale; the check gets re-evaluated. This separation reduces supervision and keeps the report from becoming a frozen truth.
\nThe new stage adds continuity to the work: a verifiable finding can become a change proposal separate from the snapshot, pass through a pull request and reach an owner with deployment authority. The map helps choose where to look; the contract determines what evidence to deliver; the deployment path governs when writing is allowed.
\nThese are different checks:
\n| Check | \nWhat it establishes | \nWhat it does not establish | \n
|---|---|---|
| Finding check | \nWhether the code satisfies a specific condition | \nWhether the whole process works correctly | \n
| Comparison with the production baseline | \nWhether drift is detected under normalized comparison since the proposal was prepared | \nChanges erased by normalization, semantic equivalence or unchanged dependencies | \n
| Download after deployment | \nWhether downloaded code matches what was sent under the implemented comparison | \nWhether business effects are as expected | \n
An idempotency fix, for example, can have a static check detecting its guard condition and still need a repeated-execution test to demonstrate that it does not duplicate effects. Having validar.sh improves review; it does not justify confusing code inspection with comprehensive validation.
The multiuser-stage documentation records controls tested with writes disabled and keeps the first real deployment from cambios/ pending. The full workflow is the direction implemented by the project, with that operational validation still open. The pilot below demonstrates analysis and its deliverables, not a subsequent deployment.
A branch with no previous manual was analyzed following only the contract. The agent delivered the three files and the priority findings were verified against the code.
\nThe test found idempotency bugs, incomplete validations and external execution surface that needed review. The anonymization rules keep the problem categories, but do not publish the flow, the names or the client’s exact conditions.
\nThe analysis also flagged as unconfirmed the points the API did not allow checking. That discipline was part of the success, not a limitation to hide.
\nFor an unfamiliar flow, start with the map, contract and checks before preparing changes. Once a finding has evidence, use the function platform to organize the proposal and the separation of authorities to bound publication. A broad redesign or a condition that the snapshot cannot establish needs a different investigation; it should not be disguised as a fix ready to deploy.
\nDiagnostic capability stopped depending on whoever knows the organization by heart. The core cost is generating the snapshot and reports; each team member can analyze a branch with their own tool and verify fixes without production access.
\n", "headings": [ { "label": "The second-stage leap", "depth": 2, "id": "the-second-stage-leap" }, { "label": "Generated and curated", "depth": 2, "id": "generated-and-curated" }, { "label": "Unit of work: one branch", "depth": 2, "id": "unit-of-work-one-branch" }, { "label": "The limit that sustains quality", "depth": 2, "id": "the-limit-that-sustains-quality" }, { "label": "Verification without AI", "depth": 2, "id": "verification-without-ai" }, { "label": "From finding to deployable proposal", "depth": 2, "id": "from-finding-to-deployable-proposal" }, { "label": "Pilot test", "depth": 2, "id": "pilot-test" }, { "label": "Choosing the next step", "depth": 2, "id": "choosing-the-next-step" }, { "label": "The benefit", "depth": 2, "id": "the-benefit" } ], "raw": "---\nslug: mapa-procesos-verificacion\ntitle: From backup to process map\ntype: case-study\norder: 3\nsummary: The process map enables analysis without production access; the new change path connects verifiable findings with review and controlled deployment.\ntags: [processes, audit, agents, verification, zoho-crm]\nrelated: [backup-versionado-crm, arquitectura-read-only, orquestacion]\narea: CRM versionado\nglyph: ⌘\nhue: rgba(168,106,255,.24)\n---\n\n# From backup to process map\n\n> Updated on October 12, 2026. The analysis pilot is preserved and distinguished from the subsequent multiuser deployment stage.\n\n## The second-stage leap\n\nThe backup answered what code existed. It did not explain how the business was organized, which functions made up a flow or how to check that a fix had been applied.\n\nThe second stage added three pieces:\n\n| Piece | What it answers |\n| --- | --- |\n| Resource dictionary | Which functions use each shared resource and what the blast radius is |\n| Process tree | Which flows exist and which functions make up each branch |\n| Analysis contract | How a branch should be analyzed and what evidence to deliver |\n\n## Generated and curated\n\nData that changes is regenerated on every sync. The conceptual organization is expressed through rules maintained by people.\n\nNo manual lists of functions are written into the documentation: they go stale the next day. A rule absorbs new functions and the report flags those that do not fit any branch.\n\n## Unit of work: one branch\n\nThe process for a person or agent is deliberately bounded:\n\n1. Open a working copy of the repository.\n2. Pick a branch from the process tree.\n3. Follow the analysis contract.\n4. Deliver three artifacts.\n\n| Deliverable | Purpose |\n| --- | --- |\n| `manual-operativo.md` | Explain the flow in business terms |\n| `mejoras-propuestas.md` | Rank findings by consequence, anchored to file and line |\n| `validar.sh` | Turn every finding into an executable check |\n\nIn the original test, the agent started from computed reports rather than a blind search across more than thirteen hundred functions. That size describes the inventory at the time, not an updated count. The advantage of the method is bounded context and repeatable analysis.\n\n## The limit that sustains quality\n\nThe analysis fixes visible defects; it does not redesign processes or propose broad migrations. On a platform where publishing is immediate, a large redesign of a flow that moves money needs another level of governance.\n\nThe restriction does not live only in the prompt: **every finding that gets developed must be expressible as an automated check**. If it cannot be verified, it is noted as a separate idea and not presented as a ready fix.\n\n## Verification without AI\n\nWhen someone reports they fixed a finding, there is no need to pay for reasoning again to read the code. You run `validar.sh` against the current snapshot.\n\nProse goes stale; the check gets re-evaluated. This separation reduces supervision and keeps the report from becoming a frozen truth.\n\n## From finding to deployable proposal\n\nThe new stage adds continuity to the work: a verifiable finding can become a change proposal separate from the snapshot, pass through a pull request and reach an owner with deployment authority. The map helps choose where to look; the contract determines what evidence to deliver; the deployment path governs when writing is allowed.\n\nThese are different checks:\n\n| Check | What it establishes | What it does not establish |\n| --- | --- | --- |\n| Finding check | Whether the code satisfies a specific condition | Whether the whole process works correctly |\n| Comparison with the production baseline | Whether drift is detected under normalized comparison since the proposal was prepared | Changes erased by normalization, semantic equivalence or unchanged dependencies |\n| Download after deployment | Whether downloaded code matches what was sent under the implemented comparison | Whether business effects are as expected |\n\nAn idempotency fix, for example, can have a static check detecting its guard condition and still need a repeated-execution test to demonstrate that it does not duplicate effects. Having `validar.sh` improves review; it does not justify confusing code inspection with comprehensive validation.\n\nThe multiuser-stage documentation records controls tested with writes disabled and keeps the first real deployment from `cambios/` pending. The full workflow is the direction implemented by the project, with that operational validation still open. The pilot below demonstrates analysis and its deliverables, not a subsequent deployment.\n\n## Pilot test\n\nA branch with no previous manual was analyzed following only the contract. The agent delivered the three files and the priority findings were verified against the code.\n\nThe test found idempotency bugs, incomplete validations and external execution surface that needed review. The anonymization rules keep the problem categories, but do not publish the flow, the names or the client’s exact conditions.\n\nThe analysis also flagged as unconfirmed the points the API did not allow checking. That discipline was part of the success, not a limitation to hide.\n\n## Choosing the next step\n\nFor an unfamiliar flow, start with the map, contract and checks before preparing changes. Once a finding has evidence, use the [function platform](/en/entrada/backup-versionado-crm) to organize the proposal and the [separation of authorities](/en/entrada/arquitectura-read-only) to bound publication. A broad redesign or a condition that the snapshot cannot establish needs a different investigation; it should not be disguised as a fix ready to deploy.\n\n## The benefit\n\nDiagnostic capability stopped depending on whoever knows the organization by heart. The core cost is generating the snapshot and reports; each team member can analyze a branch with their own tool and verify fixes without production access.\n", "language": "en" }, { "slug": "caso-tablero-continuidad-operativa", "title": "Case study — From counter to operational continuity dashboard", "summary": "A personal tool grew to combine incidents, service health and progressive signals without bringing credentials into the browser.", "type": "case-study", "order": 1, "tags": [ "case-study", "observability", "astro", "typescript", "n8n", "incidents", "security" ], "related": [ "continuidad-y-observabilidad", "caso-orca-cockpit-multiagente" ], "area": "Casos de producto", "glyph": "◌", "hue": "rgba(87,217,232,.22)", "file": "caso-tablero-continuidad-operativa.md", "html": "The first need seemed minimal: show how much time had passed since the last incident. But an isolated number did not explain what had happened, whether the problem was still open or which part of the environment was affected.
\nThe product ended up becoming a small operations center: continuity, an incident log, metrics and the health of several services on a single surface.
\n| Layer | \nTechnology | \nResponsibility | \n
|---|---|---|
| Interface | \nAstro + Tailwind CSS | \nFast, responsive static site that is easy to deploy | \n
| Domain | \nTypeScript | \nContinuity calculation, states, normalization and signal merging | \n
| Local fallback | \nlocalStorage | \nKeep actions when the remote layer does not respond | \n
| Integration | \nn8n | \nIncident persistence and running checks | \n
| Persistence | \nData Tables | \nSyncing history across devices | \n
| Delivery | \nStatic hosting with security policies | \nPublishing the frontend with no embedded secrets | \n
The central decision was to keep the browser as the consumer of a narrow contract. Authenticated access and credentials stayed on the integration layer’s side, which only published normalized states.
\nAn incident is not just a reset date. It has a real start, a reporting time, a status, a closure and an optional resolution note.
\nModeling it that way solved cases the simple counter was hiding:
\nThe interface went from celebrating a number to honestly representing the operational state.
\nChecks were split into groups and the frontend requested them in parallel. Each partial response is merged with the existing state without erasing services that branch did not observe.
\nThis let a known outage show up as soon as it was detected, even while other sources were still slow. It also required explicit rules to avoid races, stale data and misleading transient states.
\nNot every successful HTTP response proves the service is healthy. A frontend can return its generic HTML for a nonexistent route and produce a false green.
\nThat is why the dashboard distinguishes:
\nSeparating liveness from readiness avoided alerting every normal restart as an outage. Validating the body as well as the HTTP code avoided green checks that did not actually measure anything.
\nHardening was not left for the end:
\nWorkflows were also treated as code: their nodes, contracts and paths were checked to catch generation errors, duplicated groups and crossed responses.
\nUseful observability is not about adding checks. It is about defining what each signal proves, what it cannot prove and how incomplete results are combined without lying to the operator.
\nThe counter remained the central image, but the real product became the continuity model behind it.
\n\n\n", "headings": [ { "label": "The starting point", "depth": 2, "id": "the-starting-point" }, { "label": "The architecture that made it possible", "depth": 2, "id": "the-architecture-that-made-it-possible" }, { "label": "From a timestamp to a lifecycle", "depth": 2, "id": "from-a-timestamp-to-a-lifecycle" }, { "label": "Progressive health, not a monolithic wait", "depth": 2, "id": "progressive-health-not-a-monolithic-wait" }, { "label": "Semantics before color", "depth": 3, "id": "semantics-before-color" }, { "label": "Security and resilience as part of the product", "depth": 2, "id": "security-and-resilience-as-part-of-the-product" }, { "label": "Benefits", "depth": 2, "id": "benefits" }, { "label": "The transferable lesson", "depth": 2, "id": "the-transferable-lesson" } ], "raw": "---\nslug: caso-tablero-continuidad-operativa\ntitle: Case study — From counter to operational continuity dashboard\ntype: case-study\norder: 1\nsummary: A personal tool grew to combine incidents, service health and progressive signals without bringing credentials into the browser.\ntags: [case-study, observability, astro, typescript, n8n, incidents, security]\nrelated: [continuidad-y-observabilidad, caso-orca-cockpit-multiagente]\narea: Casos de producto\nglyph: ◌\nhue: rgba(87,217,232,.22)\n---\n\n# Case study — From counter to operational continuity dashboard\n\n## The starting point\n\nThe first need seemed minimal: show how much time had passed since the last incident. But an isolated number did not explain what had happened, whether the problem was still open or which part of the environment was affected.\n\nThe product ended up becoming a small operations center: continuity, an incident log, metrics and the health of several services on a single surface.\n\n## The architecture that made it possible\n\n| Layer | Technology | Responsibility |\n|---|---|---|\n| Interface | Astro + Tailwind CSS | Fast, responsive static site that is easy to deploy |\n| Domain | TypeScript | Continuity calculation, states, normalization and signal merging |\n| Local fallback | `localStorage` | Keep actions when the remote layer does not respond |\n| Integration | n8n | Incident persistence and running checks |\n| Persistence | Data Tables | Syncing history across devices |\n| Delivery | Static hosting with security policies | Publishing the frontend with no embedded secrets |\n\nThe central decision was to keep the browser as the consumer of a narrow contract. Authenticated access and credentials stayed on the integration layer’s side, which only published normalized states.\n\n## From a timestamp to a lifecycle\n\nAn incident is not just a reset date. It has a real start, a reporting time, a status, a closure and an optional resolution note.\n\nModeling it that way solved cases the simple counter was hiding:\n\n- an open incident stops the continuity count and avoids a false “all good”;\n- several incidents can overlap;\n- the new healthy period starts after the last effective closure;\n- old records can still be read without rewriting history;\n- a connectivity outage does not force you to lose the local creation or closure.\n\nThe interface went from celebrating a number to honestly representing the operational state.\n\n## Progressive health, not a monolithic wait\n\nChecks were split into groups and the frontend requested them in parallel. Each partial response is merged with the existing state without erasing services that branch did not observe.\n\nThis let a known outage show up as soon as it was detected, even while other sources were still slow. It also required explicit rules to avoid races, stale data and misleading transient states.\n\n### Semantics before color\n\nNot every successful HTTP response proves the service is healthy. A frontend can return its generic HTML for a nonexistent route and produce a false green.\n\nThat is why the dashboard distinguishes:\n\n- **operational:** the expected signal responded and its content is valid;\n- **degraded:** the process is alive but cannot serve correctly yet;\n- **down:** there is concrete evidence of unavailability;\n- **unverifiable:** there was a response, but it does not prove the condition being checked;\n- **no data or checking:** there is not yet a sufficient reading.\n\nSeparating liveness from readiness avoided alerting every normal restart as an outage. Validating the body as well as the HTTP code avoided green checks that did not actually measure anything.\n\n## Security and resilience as part of the product\n\nHardening was not left for the end:\n\n- the frontend never receives provider credentials;\n- a strict CSP limits unexpected execution;\n- dependencies are audited and updated;\n- accepted endpoints are normalized and restricted;\n- partial states keep the last valid observation;\n- animations respect reduced-motion preferences;\n- the scrolling area can be navigated with the keyboard.\n\nWorkflows were also treated as code: their nodes, contracts and paths were checked to catch generation errors, duplicated groups and crossed responses.\n\n## Benefits\n\n- a shared reading of continuity, incidents and dependencies;\n- earlier detection thanks to progressive responses;\n- fewer false positives and false greens;\n- continued use during temporary integration failures;\n- a clear boundary between public visualization and authenticated access;\n- verifiable behavior even when the automation lives outside the traditional repository.\n\n## The transferable lesson\n\nUseful observability is not about adding checks. It is about defining what each signal proves, what it cannot prove and how incomplete results are combined without lying to the operator.\n\nThe counter remained the central image, but the real product became the continuity model behind it.\n\n> Case based on a real implementation. Names, domains, endpoints, quantities, internal providers and identifiable operational data have been removed.\n", "language": "en" }, { "slug": "caso-widgets-crm-flujos-guiados", "title": "Case study — Widgets that turn CRM rules into guided flows", "summary": "Two embedded widgets brought context, validation and automation to the exact point where the team made decisions.", "type": "case-study", "order": 2, "tags": [ "case-study", "crm", "widgets", "javascript", "deluge", "n8n", "integrations", "ux" ], "related": [ "backup-versionado-crm", "arquitectura-read-only", "modelos-guiados-el-entorno-es-la-politica" ], "area": "Casos de producto", "glyph": "◆", "hue": "rgba(236,95,189,.24)", "file": "caso-widgets-crm-flujos-guiados.md", "html": "Case based on a real implementation. Names, domains, endpoints, quantities, internal providers and identifiable operational data have been removed.
\n
The CRM concentrated data and automations, but some tasks still required knowing too many rules by heart: which options were valid, which limits applied, when an approval was needed and how to report a problem without losing the originating context.
\nThe solution was not to build another separate application. We built embedded widgets that appeared inside the record and turned those rules into guided paths.
\nThe first widget brings together the record’s configuration, the current catalog, payment methods, installments, discounts, additional conditions and a possible counteroffer.
\nBefore allowing a confirmation, it:
\nThe interface makes the policy visible while the person is deciding. It does not depend on them remembering an external table or discovering the error after saving.
\nThe second widget can be opened from different modules. It detects the source entity and record, retrieves its context and prepares a report linked from the start.
\nA categorized search replaces a long list and lets you browse or find a problem type regardless of case and accents. The selection must come from the catalog: typing similar text is not enough to submit an ambiguous classification.
\nIt also handles attachments, loading states, partial errors and modules that do not yet have all their fields confirmed. The main flow stays operational even if secondary diagnostic information fails.
\n| Piece | \nRole | \n
|---|---|
| HTML/CSS/JavaScript widget | \nFast interaction inside the CRM iframe | \n
| Widget SDK | \nPage context, reading the record, attachments and closing the popup | \n
| CRM functions | \nPrepared data and rules close to the business model | \n
| Webhook | \nExplicit output contract | \n
| n8n | \nOrchestration of writes and follow-up actions | \n
| CRM | \nSource of truth and final traceability | \n
The boundary was deliberate: the widget guides, validates and presents; the functions retrieve context; the automation coordinates the write. No piece needs to pretend to be the whole system.
\nA limit that only exists in documentation arrives too late. Showing it next to the affected control cuts down on trial, error and side questions.
\nA wrong stage blocks the whole path. An invalid combination blocks only that alternative. A failed attachment is reported without hiding that the main record was already created.
\nLoading, technical error, context not enabled and normal flow have separate screens. This avoids mixed interfaces where it seems possible to confirm while critical information is still missing.
\nThe SDK and its responses do not always arrive in the ideal shape. We added watchdogs, defensive parsing, double-submit protection and isolated diagnostics so a secondary failure does not break the essential controls.
\nThe report is born linked to the record it was opened from. That removes the manual search afterward and improves the quality of the information the person solving the problem receives.
\nA good CRM widget is not a prettier form. It is a translation layer between the data model, business policy and human decision.
\nWhen the control appears at the point of work, prevention stops depending on perfect training: the environment itself leads toward a valid action.
\n\n\n", "headings": [ { "label": "The underlying problem", "depth": 2, "id": "the-underlying-problem" }, { "label": "Two paths, one idea", "depth": 2, "id": "two-paths-one-idea" }, { "label": "Selecting and confirming a proposal", "depth": 3, "id": "selecting-and-confirming-a-proposal" }, { "label": "Contextual problem reporting", "depth": 3, "id": "contextual-problem-reporting" }, { "label": "Integration architecture", "depth": 2, "id": "integration-architecture" }, { "label": "Decisions that paid off", "depth": 2, "id": "decisions-that-paid-off" }, { "label": "Rules visible at the right moment", "depth": 3, "id": "rules-visible-at-the-right-moment" }, { "label": "Proportional blocking", "depth": 3, "id": "proportional-blocking" }, { "label": "Mutually exclusive states", "depth": 3, "id": "mutually-exclusive-states" }, { "label": "Robustness in an embedded environment", "depth": 3, "id": "robustness-in-an-embedded-environment" }, { "label": "Context that travels with the action", "depth": 3, "id": "context-that-travels-with-the-action" }, { "label": "Benefits", "depth": 2, "id": "benefits" }, { "label": "The transferable lesson", "depth": 2, "id": "the-transferable-lesson" } ], "raw": "---\nslug: caso-widgets-crm-flujos-guiados\ntitle: Case study — Widgets that turn CRM rules into guided flows\ntype: case-study\norder: 2\nsummary: Two embedded widgets brought context, validation and automation to the exact point where the team made decisions.\ntags: [case-study, crm, widgets, javascript, deluge, n8n, integrations, ux]\nrelated: [backup-versionado-crm, arquitectura-read-only, modelos-guiados-el-entorno-es-la-politica]\narea: Casos de producto\nglyph: ◆\nhue: rgba(236,95,189,.24)\n---\n\n# Case study — Widgets that turn CRM rules into guided flows\n\n## The underlying problem\n\nThe CRM concentrated data and automations, but some tasks still required knowing too many rules by heart: which options were valid, which limits applied, when an approval was needed and how to report a problem without losing the originating context.\n\nThe solution was not to build another separate application. We built embedded widgets that appeared inside the record and turned those rules into guided paths.\n\n## Two paths, one idea\n\n### Selecting and confirming a proposal\n\nThe first widget brings together the record’s configuration, the current catalog, payment methods, installments, discounts, additional conditions and a possible counteroffer.\n\nBefore allowing a confirmation, it:\n\n- checks that the record is at the right stage;\n- filters options by context;\n- calculates amounts and installments in real time;\n- applies different limits depending on the type of proposal;\n- disables incompatible combinations and explains why;\n- routes exceptions to the approver role;\n- attaches documentation when needed;\n- builds a single payload and prevents duplicate submissions.\n\nThe interface makes the policy visible while the person is deciding. It does not depend on them remembering an external table or discovering the error after saving.\n\n### Contextual problem reporting\n\nThe second widget can be opened from different modules. It detects the source entity and record, retrieves its context and prepares a report linked from the start.\n\nA categorized search replaces a long list and lets you browse or find a problem type regardless of case and accents. The selection must come from the catalog: typing similar text is not enough to submit an ambiguous classification.\n\nIt also handles attachments, loading states, partial errors and modules that do not yet have all their fields confirmed. The main flow stays operational even if secondary diagnostic information fails.\n\n## Integration architecture\n\n| Piece | Role |\n|---|---|\n| HTML/CSS/JavaScript widget | Fast interaction inside the CRM iframe |\n| Widget SDK | Page context, reading the record, attachments and closing the popup |\n| CRM functions | Prepared data and rules close to the business model |\n| Webhook | Explicit output contract |\n| n8n | Orchestration of writes and follow-up actions |\n| CRM | Source of truth and final traceability |\n\nThe boundary was deliberate: the widget guides, validates and presents; the functions retrieve context; the automation coordinates the write. No piece needs to pretend to be the whole system.\n\n## Decisions that paid off\n\n### Rules visible at the right moment\n\nA limit that only exists in documentation arrives too late. Showing it next to the affected control cuts down on trial, error and side questions.\n\n### Proportional blocking\n\nA wrong stage blocks the whole path. An invalid combination blocks only that alternative. A failed attachment is reported without hiding that the main record was already created.\n\n### Mutually exclusive states\n\nLoading, technical error, context not enabled and normal flow have separate screens. This avoids mixed interfaces where it seems possible to confirm while critical information is still missing.\n\n### Robustness in an embedded environment\n\nThe SDK and its responses do not always arrive in the ideal shape. We added watchdogs, defensive parsing, double-submit protection and isolated diagnostics so a secondary failure does not break the essential controls.\n\n### Context that travels with the action\n\nThe report is born linked to the record it was opened from. That removes the manual search afterward and improves the quality of the information the person solving the problem receives.\n\n## Benefits\n\n- fewer invalid decisions before writing to the CRM;\n- commercial policies turned into immediate feedback;\n- exceptions routed to the right approver;\n- more consistent reports linked to their origin;\n- lower cognitive load for the operations team;\n- end-to-end traceability between interface, functions, automation and final record;\n- a reusable foundation for adding paths without taking users out of their everyday tool.\n\n## The transferable lesson\n\nA good CRM widget is not a prettier form. It is a translation layer between the data model, business policy and human decision.\n\nWhen the control appears at the point of work, prevention stops depending on perfect training: the environment itself leads toward a valid action.\n\n> Case based on two real implementations. Names, domains, internal modules, catalogs, figures, identifiers and sensitive commercial details have been removed.\n", "language": "en" }, { "slug": "caso-jev-director-narrativo", "title": "Case: a Director that separates narration from memory", "summary": "An orchestrated architecture where one model writes the scene, Jev decides its consequences and an event log rebuilds what each character can remember.", "type": "case-study", "order": 3, "tags": [ "jev", "narrative", "memory", "agents", "events", "case-study" ], "related": [ "jev-decisiones-estructuradas", "orquestacion", "continuidad-y-observabilidad" ], "area": "Casos de producto", "glyph": "◉", "hue": "rgba(236,95,189,.24)", "file": "caso-jev-director-narrativo.md", "html": "Case based on two real implementations. Names, domains, internal modules, catalogs, figures, identifiers and sensitive commercial details have been removed.
\n
In an interactive fiction app, the generative model could produce scenes and dialogue. The challenge was keeping the consequences: who discovered a secret, which promise was left pending, how a relationship changed and which theme was still open.
\nA long chat is not a stable source for reconstructing all of that. Repeating the whole history to the narrator eats context and does not guarantee it can tell a lasting fact from an interpretation or an everyday gesture. v2 added a Director that observes every turn and keeps a narrative state separate from the prose.
\nThe flow splits responsibilities:
\nreplay.The Director has a core of events and reducers with no model calls; the part that queries Jev lives separately. That way the state logic can be tested without a network and you can check where each consequence came from.
\nCandidates are directed pairs between the protagonist and the other characters present. Direction matters: A’s trust in B can change even if B’s trust in A does not. The first call to Jev asks, in batch, whether there was a genuine change; a second call evaluates dimension, direction and magnitude only for the selected candidates.
\nTests showed that a pleasant gesture could get too much weight if you only looked at the intensity of the moment. The calculation added two more signals: the probability that the relationship actually changed and whether someone learned something new about the other person. An everyday coffee and a revelation leave different marks.
\nThe code caps the maximum delta per scene and flips the sign when it relates to tension: improving a relationship can lower tension while trust or closeness go up. It also correctly normalizes Score before applying the change; the raw value represents the criteria scale defined in the question.
\nFor the narrative state, a compiler proposes third-person claims. Jev classifies them as a lasting fact, an open theme, a promise or nothing. Then it compares candidates against what is already recorded and against others from the same turn to avoid semantic duplicates.
\nThe question “who found out?” is asked separately. A character being in the scene does not mean they heard a private conversation or understood an allusion. If they find out several turns later, the list of those who know the same fact is updated; no new identical fact is invented.
\nThe resulting events feed a log from which the state is rebuilt. The summary the narrator receives includes facts known to someone present, relationships expressed in words and pending matters. Memories are also filtered by timeline: a future event or one that happened only on another branch does not get in. That last filter is a code rule, not a Jev decision.
\nThe Director is implemented on a v2 branch and was calibrated with hand-annotated story fragments. There was also a blind comparison of the narrator’s response with and without the Director’s summary on a real session: 20 pairs; 7 preferences for the version with the summary, 5 for the one without it and 8 ties. It is limited evidence of coherence; it does not show a clear improvement in writing quality.
\nAttributing who knows what still fails in implicit scenes; in manual tests, a generative model used as a judge solved some examples better. Conditional promises also go undetected, and a network failure when querying Jev can still cut the turn short. v2 is under evaluation, with work pending before treating it as a finished solution.
\nThe separation leaves a readable contract: one model writes, another helps decide what consequences there were, and the code determines what gets recorded and what can be remembered. Jev contributes structured decisions where the question is small and verifiable; the Director contributes rules, traceability and temporal limits.
\nThe value of the case is not in adding a model to the pipeline. It is in being able to point to a turn, a decision and an event when the story remembers something it should not, or forgets something that did happen.
\n\n\n", "headings": [ { "label": "The problem that showed up after writing", "depth": 2, "id": "the-problem-that-showed-up-after-writing" }, { "label": "The orchestration", "depth": 2, "id": "the-orchestration" }, { "label": "Relationships: a moment mattering does not mean everything changes", "depth": 2, "id": "relationships-a-moment-mattering-does-not-mean-everything-changes" }, { "label": "Facts: knowing something is not the same as being nearby", "depth": 2, "id": "facts-knowing-something-is-not-the-same-as-being-nearby" }, { "label": "What the test lets us claim", "depth": 2, "id": "what-the-test-lets-us-claim" }, { "label": "The architectural decision", "depth": 2, "id": "the-architectural-decision" } ], "raw": "---\nslug: caso-jev-director-narrativo\ntitle: \"Case: a Director that separates narration from memory\"\ntype: case-study\norder: 3\nsummary: \"An orchestrated architecture where one model writes the scene, Jev decides its consequences and an event log rebuilds what each character can remember.\"\ntags: [jev, narrative, memory, agents, events, case-study]\nrelated: [jev-decisiones-estructuradas, orquestacion, continuidad-y-observabilidad]\narea: Casos de producto\nglyph: ◉\nhue: rgba(236,95,189,.24)\n---\n\n# Case: a Director that separates narration from memory\n\n## The problem that showed up after writing\n\nIn an interactive fiction app, the generative model could produce scenes and dialogue. The challenge was keeping the consequences: who discovered a secret, which promise was left pending, how a relationship changed and which theme was still open.\n\nA long chat is not a stable source for reconstructing all of that. Repeating the whole history to the narrator eats context and does not guarantee it can tell a lasting fact from an interpretation or an everyday gesture. v2 added a **Director** that observes every turn and keeps a narrative state separate from the prose.\n\n## The orchestration\n\nThe flow splits responsibilities:\n\n1. **Narrator:** writes the scene and returns actions with the characters identified.\n2. **Candidate builder:** builds relationship pairs from those identifiers. A small compiler proposes claims about facts, themes and promises.\n3. **Jev:** answers typed questions about relationship changes, narrative categories, equivalence with recorded matters and who found out.\n4. **Domain code:** turns valid decisions into events, limits their effect and rebuilds state through `replay`.\n5. **Next-turn context:** summarizes what matters for the narrator and retrieves only the memories that belong to that point in the story.\n\nThe Director has a core of events and reducers with no model calls; the part that queries Jev lives separately. That way the state logic can be tested without a network and you can check where each consequence came from.\n\n## Relationships: a moment mattering does not mean everything changes\n\nCandidates are directed pairs between the protagonist and the other characters present. Direction matters: A’s trust in B can change even if B’s trust in A does not. The first call to Jev asks, in batch, whether there was a genuine change; a second call evaluates dimension, direction and magnitude only for the selected candidates.\n\nTests showed that a pleasant gesture could get too much weight if you only looked at the intensity of the moment. The calculation added two more signals: the probability that the relationship actually changed and whether someone learned something new about the other person. An everyday coffee and a revelation leave different marks.\n\nThe code caps the maximum delta per scene and flips the sign when it relates to tension: improving a relationship can lower tension while trust or closeness go up. It also correctly normalizes *Score* before applying the change; the raw value represents the criteria scale defined in the question.\n\n## Facts: knowing something is not the same as being nearby\n\nFor the narrative state, a compiler proposes third-person claims. Jev classifies them as a lasting fact, an open theme, a promise or nothing. Then it compares candidates against what is already recorded and against others from the same turn to avoid semantic duplicates.\n\nThe question “who found out?” is asked separately. A character being in the scene does not mean they heard a private conversation or understood an allusion. If they find out several turns later, the list of those who know **the same fact** is updated; no new identical fact is invented.\n\nThe resulting events feed a log from which the state is rebuilt. The summary the narrator receives includes facts known to someone present, relationships expressed in words and pending matters. Memories are also filtered by timeline: a future event or one that happened only on another branch does not get in. That last filter is a code rule, not a Jev decision.\n\n## What the test lets us claim\n\nThe Director is implemented on a v2 branch and was calibrated with hand-annotated story fragments. There was also a blind comparison of the narrator’s response with and without the Director’s summary on a real session: **20 pairs; 7 preferences for the version with the summary, 5 for the one without it and 8 ties**. It is limited evidence of coherence; it does not show a clear improvement in writing quality.\n\nAttributing who knows what still fails in implicit scenes; in manual tests, a generative model used as a judge solved some examples better. Conditional promises also go undetected, and a network failure when querying Jev can still cut the turn short. v2 is under evaluation, with work pending before treating it as a finished solution.\n\n## The architectural decision\n\nThe separation leaves a readable contract: **one model writes, another helps decide what consequences there were, and the code determines what gets recorded and what can be remembered**. Jev contributes structured decisions where the question is small and verifiable; the Director contributes rules, traceability and temporal limits.\n\nThe value of the case is not in adding a model to the pipeline. It is in being able to point to a turn, a decision and an event when the story remembers something it should not, or forgets something that did happen.\n\n> Case based on a working v2 under evaluation. Product, characters, sessions and repository details were anonymized; the figures come from a limited comparative test, not a production measurement.\n", "language": "en" }, { "slug": "tailscale-entorno-agentes", "title": "Tailscale for an agent environment: laptop, VPS, and WSL", "summary": "An anonymized reference design for accessing a workstation, operating a VPS, and sharing internal previews without exposing admin ports.", "type": "guide", "order": 10, "tags": [ "tailscale", "orca", "wsl", "vps", "ssh", "agents" ], "related": [ "tailscale-red-privada-identidad", "tailscale-permisos-grants", "acceso-portatil-orca", "hosts-ssh" ], "area": "Casos de producto", "glyph": "◆", "hue": "rgba(237,195,94,.24)", "file": "tailscale-entorno-agentes.md", "html": "Case based on a working v2 under evaluation. Product, characters, sessions and repository details were anonymized; the figures come from a limited comparative test, not a production measurement.
\n
A developer uses Windows with WSL 2 for repositories, agents, and local processes. They also operate a VPS and want to connect from a laptop while away. The goal is to keep one workstation and give specific operations private routes. This is an anonymized reference design, not a claim that a deployment has already been verified.
\nThe portable Orca access guide describes the continuity goal. Here we expand it to include the VPS and development previews.
\n| From | \nTo | \nPurpose | \nBoundary | \n
|---|---|---|---|
| Laptop | \nWindows/WSL host | \nOrca and SSH | \nOnly the authorized identity and port | \n
| Workstation | \nVPS | \nAdministration or internal API | \nOnly necessary services | \n
| Invited teammate | \nLocal preview | \nUI review | \nTemporary, restricted access | \n
The laptop is a client; repos, runtime credentials, and branches stay on the workstation. The VPS has its own machine identity. Agents may use these routes, but their ability to change code or production still depends on service credentials, permissions, and workflow approvals.
\nTailscale documents a conflict when it runs on Windows and inside WSL 2 at the same time: encrypted WSL traffic over the Windows host's Tailscale can fail because of packet size. This design therefore starts with Tailscale on Windows and a single Tailscale instance. If a remote client needs sshd inside WSL, verify the Windows → WSL route, listen address and port, firewall, and current WSL networking mode. Do not assume the Windows tailnet IP automatically leads to Linux. Tailscale on WSL 2
Before changing network rules, verify that Windows itself can connect to WSL SSH. Then test from the laptop through the Windows host's Tailscale address. Repeat after WSL networking updates. Running Tailscale only inside WSL is another possible design, but requires checking its lifecycle and the documented MTU considerations.
\nTailscale can give the VPS a stable private destination for SSH or an internal API. An automated server should use a machine identity with a tag and managed authentication; auth keys should not be pasted into repositories or images. Policy might allow workstation → VPS TCP 22 or 443 while excluding the database. SSH and the application still validate users, sessions, and actions. Setting up servers · Auth keys
\nFor containers, decide whether Tailscale lives on the host with a proxy to the container or in its own container with persistent state and separate authentication. The first has fewer identities to manage for a few apps; the second allows an independent lifecycle. Neither automatically opens every Docker network. Docker parameters
\nTailscale Serve routes a local service to the tailnet and respects its access controls. Funnel exposes a local service to the public internet: use it for a deliberately public demo with application controls and a clear end date. For an internal dashboard review, start with Serve. Check current documentation for the command and prerequisites, as the syntax has changed over time. Serve · Funnel
\nThe practical outcome is mobility without parallel clones, a VPS reachable through a private route, and previews with an explicit audience. The network connects the pieces; application authorization and operational continuity remain team responsibilities.
\n", "headings": [ { "label": "The scenario", "depth": 2, "id": "the-scenario" }, { "label": "Connection map", "depth": 2, "id": "connection-map" }, { "label": "The awkward WSL 2 decision", "depth": 2, "id": "the-awkward-wsl-2-decision" }, { "label": "Operate the VPS without confusing connectivity with authority", "depth": 2, "id": "operate-the-vps-without-confusing-connectivity-with-authority" }, { "label": "Serve and Funnel have different audiences", "depth": 2, "id": "serve-and-funnel-have-different-audiences" }, { "label": "An afternoon preflight", "depth": 2, "id": "an-afternoon-preflight" } ], "raw": "---\nslug: tailscale-entorno-agentes\ntitle: \"Tailscale for an agent environment: laptop, VPS, and WSL\"\ntype: guide\norder: 10\nsummary: \"An anonymized reference design for accessing a workstation, operating a VPS, and sharing internal previews without exposing admin ports.\"\ntags: [tailscale, orca, wsl, vps, ssh, agents]\nrelated: [tailscale-red-privada-identidad, tailscale-permisos-grants, acceso-portatil-orca, hosts-ssh]\narea: Casos de producto\nglyph: ◆\nhue: rgba(237,195,94,.24)\n---\n\n# Tailscale for an agent environment: laptop, VPS, and WSL\n\n## The scenario\n\nA developer uses Windows with WSL 2 for repositories, agents, and local processes. They also operate a VPS and want to connect from a laptop while away. The goal is to keep **one workstation** and give specific operations private routes. This is an anonymized reference design, not a claim that a deployment has already been verified.\n\nThe [portable Orca access guide](/entrada/acceso-portatil-orca) describes the continuity goal. Here we expand it to include the VPS and development previews.\n\n## Connection map\n\n| From | To | Purpose | Boundary |\n| --- | --- | --- | --- |\n| Laptop | Windows/WSL host | Orca and SSH | Only the authorized identity and port |\n| Workstation | VPS | Administration or internal API | Only necessary services |\n| Invited teammate | Local preview | UI review | Temporary, restricted access |\n\nThe laptop is a client; repos, runtime credentials, and branches stay on the workstation. The VPS has its own machine identity. Agents may use these routes, but their ability to change code or production still depends on service credentials, permissions, and workflow approvals.\n\n## The awkward WSL 2 decision\n\nTailscale documents a conflict when it runs **on Windows and inside WSL 2 at the same time**: encrypted WSL traffic over the Windows host's Tailscale can fail because of packet size. This design therefore starts with Tailscale **on Windows** and a single Tailscale instance. If a remote client needs `sshd` inside WSL, verify the Windows → WSL route, listen address and port, firewall, and current WSL networking mode. Do not assume the Windows tailnet IP automatically leads to Linux. [Tailscale on WSL 2](https://tailscale.com/docs/install/windows/wsl2)\n\nBefore changing network rules, verify that Windows itself can connect to WSL SSH. Then test from the laptop through the Windows host's Tailscale address. Repeat after WSL networking updates. Running Tailscale *only* inside WSL is another possible design, but requires checking its lifecycle and the documented MTU considerations.\n\n## Operate the VPS without confusing connectivity with authority\n\nTailscale can give the VPS a stable private destination for SSH or an internal API. An automated server should use a machine identity with a tag and managed authentication; auth keys should not be pasted into repositories or images. Policy might allow workstation → VPS TCP 22 or 443 while excluding the database. SSH and the application still validate users, sessions, and actions. [Setting up servers](https://tailscale.com/docs/how-to/set-up-servers) · [Auth keys](https://tailscale.com/docs/features/access-control/auth-keys)\n\nFor containers, decide whether Tailscale lives on the host with a proxy to the container or in its own container with persistent state and separate authentication. The first has fewer identities to manage for a few apps; the second allows an independent lifecycle. Neither automatically opens every Docker network. [Docker parameters](https://tailscale.com/docs/features/containers/docker/docker-params)\n\n## Serve and Funnel have different audiences\n\n**Tailscale Serve** routes a local service to the tailnet and respects its access controls. **Funnel** exposes a local service to the public internet: use it for a deliberately public demo with application controls and a clear end date. For an internal dashboard review, start with Serve. Check current documentation for the command and prerequisites, as the syntax has changed over time. [Serve](https://tailscale.com/docs/features/tailscale-serve) · [Funnel](https://tailscale.com/docs/features/tailscale-funnel)\n\n## An afternoon preflight\n\n1. Choose which side of Windows/WSL runs Tailscale; verify Windows can reach WSL SSH.\n2. Register laptop, host, and VPS with distinct identities; tag servers rather than people.\n3. Define a [minimal policy by source, destination, and port](/entrada/tailscale-permisos-grants); remove any broad rule left over.\n4. Test laptop → host and host → VPS using the real protocol. Test a connection that should fail against an **online** service.\n5. Restart WSL or the host and repeat. A powered-off workstation cannot run your agents, regardless of the tunnel.\n\nThe practical outcome is mobility without parallel clones, a VPS reachable through a private route, and previews with an explicit audience. The network connects the pieces; application authorization and operational continuity remain team responsibilities.\n", "language": "en" } ] }