DEV Community: Orquesta𝄢

How Real-time Log Streaming Transforms AI Debugging

Orquesta𝄢 — Sun, 01 Nov 2026 12:01:34 +0000

Originally published at getorquesta.com/blog/real-time-log-streaming-ai-debugging-2026-11-01

When we first built Orquesta, we treated AI agent output like a batch job. You'd submit a prompt, wait a few minutes, and then get a final result—a pull request, a deployed service, or an error message. If something went wrong, you'd have to reverse-engineer what happened from the end state and a dump of logs that arrived all at once. It was like debugging a compiled program without a debugger: you saw the core dump, but not the steps that led to it.

That changed when we implemented real-time log streaming. Now, every line the agent produces—its reasoning, tool calls, file modifications, test results—appears in your terminal and dashboard the moment it's generated. This shift from batch to streaming has fundamentally altered how we debug AI systems. It's not just a convenience; it's a different debugging paradigm.

The Blind Debugging of Batch Output

Imagine you're using an AI agent to fix a bug in a codebase. The agent runs for five minutes, then reports: "I couldn't fix the bug." You're left staring at a final log dump of hundreds of lines, trying to figure out where things went wrong. Did it misread a file? Did it run the wrong command? Did it get stuck in a loop? With batch output, you only see the aftermath. You're debugging a black box.

Early Orquesta users experienced this. They'd submit prompts, go do something else, and come back to a finished run. If the result was wrong, they had to dig through the entire log history, often guessing at timestamps and ordering. Frustration mounted. We knew we needed a live view.

How Streaming Logs Work

Orquesta's agent runs locally via the Claude CLI. We spawn that CLI in a pseudo-terminal (PTY), capture its stdout and stderr in real-time, chunk the output, and push it over a WebSocket to the dashboard. Each chunk is rendered immediately in a terminal component. There's no buffering at the application level—what the agent writes is what you see, as it writes it.

Here's a snippet of a live stream while an agent fixes a null check:

[Agent] Reading file src/utils.ts
[Agent] Found potential null dereference at line 42
[Agent] Writing fix...
[Agent] Running tests: npm test
[Test] PASS src/utils.test.ts
[Agent] Committing change with message: "fix: add null check"
[Agent] Pushing to branch fix/null-check

In a batch model, you'd only see the final commit message. Here, you witness the entire process. If any step goes wrong—say the test fails—you see it immediately and can intervene before the agent proceeds further.

Early Error Detection

The most obvious benefit of streaming is catching mistakes early. AI agents are non-deterministic; they sometimes take wrong turns. Maybe the agent decides to install a package that isn't needed, or it modifies a file in a way that breaks existing tests. With streaming, you spot these errors as they happen.

I've pulled the plug on agents mid-run countless times. For example, an agent once started refactoring a function that was unrelated to the bug I asked it to fix. I saw the [Agent] Opening file src/other-module.ts line appear and immediately knew it was off-track. I sent a cancel signal, adjusted my prompt to be more specific, and reran. That saved minutes and avoided clean-up of unwanted changes.

Without streaming, that agent would have completed its erroneous refactor, committed it, and I'd have discovered the problem only when reviewing the PR—or worse, after it was merged.

Building Trust in AI-Generated Code

Beyond debugging, streaming logs build trust. When you watch an agent work, you understand its reasoning. You see it read relevant files, run tests, fix failures, and iterate. This transparency demystifies the "black box." You're not just receiving code from nowhere; you're watching a logical process unfold.

For teams adopting AI-generated code, this is crucial. Engineers are rightly skeptical of code they didn't write. But if they can observe the agent's step-by-step actions—and verify each one—they're more likely to trust the final result. The log stream becomes a form of documentation: a trace of how the solution was arrived at.

In Orquesta, every action is a real git commit, and the live logs show the thinking behind each commit. You can jump into the history and see exactly what the agent was doing at any point. This auditability is essential for production use.

Real-World Workflow: Debugging a Deployment with Streaming

Let me walk through a concrete example from our own development. We had a failing deployment in a microservice. The error was intermittent and hard to reproduce. I submitted a prompt to the agent: "Investigate the intermittent 500 errors in the payment service and propose a fix."

With streaming, I watched the agent work in real-time:

[Agent] Fetching recent logs from production...
[Agent] Found error pattern: null pointer in calculateTotal()
[Agent] Reading payment/service.ts
[Agent] Identified race condition on shared state
[Agent] Writing test to reproduce...
[Agent] Test reproduces issue: 3/10 runs fail
[Agent] Applying mutex lock around shared state
[Agent] Running tests...
[Test] All 10/10 runs pass
[Agent] Committing fix: "fix: add mutex to prevent race condition"

Within two minutes, I saw the agent pinpoint the race condition and verify the fix. If I had waited for batch output, I would have seen only the final commit. But by watching, I gained confidence that the agent truly understood the problem and didn't just apply a band-aid.

Even more importantly, I could have caught a wrong approach early. Suppose the agent had decided to add a retry loop instead of fixing the race condition. I would have seen that in the stream and redirected it.

Implementation Details

Building streaming into Orquesta required some careful engineering. The key was using a PTY to capture raw terminal output. Regular pipes buffer output, which would introduce latency or reorder lines. A PTY gives us a byte stream exactly as the CLI produces it, including ANSI color codes and cursor movements.

We then parse and format that output for both the terminal and the dashboard. The dashboard terminal component renders the stream with minimal delay, typically under 50 milliseconds. We also store the full log in our database for audit and replay, but the live view is what enables real-time debugging.

The same streaming infrastructure powers our Agent Grid, where you can monitor dozens of agents side by side. Each agent's terminal streams live, so you can glance and see which agents are progressing, which are stuck, and which have errored. This is invaluable when running parallel tasks.

Beyond Debugging: Monitoring and Collaboration

Streaming logs also enhance team collaboration. With Orquesta, you can invite team members to watch an agent's run in real-time. Someone can submit a prompt, and others can observe the execution, offer suggestions, or even take over if needed. This shared visibility reduces communication overhead and keeps everyone on the same page.

During quality gate simulations, where the AI simulates changes before real execution, streaming lets reviewers watch the simulated run. They can see exactly what would happen if the change were applied, without actually applying it. This builds confidence in the proposed changes.

The Takeaway

Real-time log streaming has transformed how we debug AI agents. It shifts the debugging experience from post-mortem analysis to live observation. You catch errors as they occur, saving time and preventing bad commits. You build trust in AI-generated code by witnessing the agent's reasoning. And you enable collaborative monitoring at scale.

If you're building or using AI agents, don't settle for batch output. Demand streaming logs. The difference is like night and day in your ability to debug, trust, and ship. It's not a feature; it's a fundamental requirement.

No SSH, No Secrets: Team Collaboration Through Agent Prompts

Orquesta𝄢 — Thu, 29 Oct 2026 12:01:09 +0000

Originally published at getorquesta.com/blog/no-ssh-no-secrets-team-collaboration-through-agent-prompts

The SSH Access Problem

We built Orquesta after repeatedly hitting the same wall: giving teammates access to a server or local environment meant handing out SSH keys, managing jump hosts, and praying nobody ran rm -rf by accident. SSH is a blunt instrument. It exposes the entire filesystem, every environment variable, every secret. Even with strict key management, the risk surface is enormous. And for non-technical stakeholders—designers, PMs, QA—SSH is a non-starter. They shouldn't have to learn terminal commands to get something done.

The alternative was worse: asking a developer to run commands on someone else's behalf. That creates a bottleneck and breaks the flow. We needed a way to let people request work in an environment without ever touching it directly. That led to the core idea behind Orquesta: install a local agent on the machine that owns the environment, then let anyone submit prompts from a dashboard. The agent executes those prompts locally, streams output in real-time, and commits every change to git. No SSH keys shared, no shell access granted, no direct infra exposure.

How the Agent Works

Orquesta's agent runs on the machine where the actual work happens—your laptop, a staging server, a production box. It uses the Claude CLI under the hood, which means all reasoning, code generation, and command execution stays on that machine. The agent opens a local terminal session, but only through a controlled interface. It can run shell commands, edit files, create branches, and push commits—but only because the agent is configured to do so. The person submitting the prompt never sees that terminal. They just see the streamed output in the dashboard.

Here's what a typical setup looks like. Install the Orquesta CLI on your machine:

npm install -g @orquesta/cli
orquesta init

This generates a local config, starts the agent, and connects it to your Orquesta workspace. The agent authenticates using a scoped token that has no permissions beyond what the agent itself needs. You can then invite teammates to that workspace with role-based access. We support roles like Admin, Developer, Reviewer, and Observer. A Reviewer can see prompts and outputs but can't submit new ones without approval. An Observer can only view the audit log. This means a product manager can submit a prompt like "Add a dark mode toggle to the settings page" and the agent will branch, implement, test, and open a PR—all without the PM ever seeing a command line.

The Prompt-to-PR Pipeline

Let's walk through a real workflow. A teammate submits a prompt from the dashboard:

Fix the failing test in the auth module and update the docs.

The Orquesta agent receives the prompt, picks an execution mode (Auto by default), and starts working. In Auto mode, the agent decides whether to run simple shell commands directly, use the Claude agent for complex tasks, or enter Batuta mode—a ReAct loop that thinks, acts, observes, and repeats until the task is done. Batuta is especially useful for multi-step tasks like debugging a flaky test or refactoring a module.

The agent streams every line of output to the dashboard in real-time. Teammates can watch the agent's thought process, the commands it runs, and the files it touches. Every action becomes a git commit on a feature branch, so the entire history is preserved. When the agent finishes, it opens a PR with a summary. A team lead can review the diff, run quality gates, and merge. The person who submitted the prompt never needs to know how it worked. They just see a PR ready for review.

Security Without Sacrificing Speed

The biggest objection we hear is: "If the agent can run commands on my machine, isn't that just as dangerous as SSH?" The answer is no, because the agent operates within a defined scope. It doesn't expose raw shell access to anyone. The person submitting a prompt can't type arbitrary commands—they can only submit natural language prompts, which the agent interprets. The agent's actions are further constrained by the CLAUDE.md file in your repo, which sets coding standards and allowed operations. You can also configure quality gates: before the agent executes a risky command, it can simulate the change and require a sign-off from a team lead.

All prompts, logs, diffs, and costs are encrypted with AES-256 and stored in an immutable audit trail. You can see exactly who submitted what, what the agent did, and how much it cost. If someone tries to inject a malicious prompt (e.g., "Delete the production database"), the agent's built-in safety checks and the quality gate will block it unless explicitly approved. We built this because we were tired of worrying about who had root access.

Collaboration Beyond the Dashboard

Orquesta isn't just a web UI. We've made it possible to collaborate from anywhere. The Telegram bot lets team members submit prompts from their phone. The Embed SDK lets you drop a single script tag into any internal tool and give users a prompt box. The Agent Grid shows all your running agents on one screen, with live terminals for each. This is invaluable for team leads managing multiple environments—you can watch six agents work in parallel and intervene if one goes off the rails.

Here's a snippet of the embed SDK:

<script src="https://cdn.orquesta.dev/embed.js"></script>
<script>
  Orquesta.mount('#prompt-box', {
    workspace: 'your-workspace-id',
    theme: 'dark'
  });
</script>

This drops a prompt submission widget into any web app. A customer support rep can submit "Regenerate the invoice for order #1234" directly from the CRM, without ever seeing a server.

A New Collaboration Model

The traditional model of infrastructure access is broken. SSH keys get shared, permissions drift, and non-technical users are locked out. Orquesta replaces that with a prompt-based interface. You install the agent on the machines you control, invite people to submit prompts, and let the AI do the work under strict guardrails. The result is faster iteration, fewer bottlenecks, and a complete audit trail. No one sees your keys, no one has shell access, and no one touches your infra directly. They just write what they want done, and the agent handles the rest.

We built Orquesta because we wanted to stop being the middlemen for every environment change. Now our team submits prompts from the dashboard, watches the agent work, and reviews the PRs. It's not just safer—it's the way software development should work.

Batuta AI: Autonomous Server Debugging via ReAct

Orquesta𝄢 — Tue, 27 Oct 2026 12:01:45 +0000

Originally published at getorquesta.com/blog/batuta-ai-autonomous-server-debugging-via-react

The Problem with Manual Debugging

When a server goes down, every minute counts. Traditional debugging means SSHing in, running commands, reading logs, and hoping you spot the issue. Scale that to dozens of VMs and it's a full-time job. We wanted to automate this, but not with brittle scripts that only handle known cases. We needed something that could reason about new problems. That's why we built Batuta AI.

Batuta is an execution mode in Orquesta that connects to cloud VMs over SSH and uses a ReAct loop (Think > Act > Observe > Repeat) to diagnose and fix issues autonomously. It doesn't just run a predefined playbook; it iterates, learns from each command's output, and decides the next step until the task is complete. I'll walk through how it works, with real examples from our own infrastructure.

ReAct Loop in Practice

The ReAct loop is the core of Batuta's intelligence. At each iteration, the model:

Think: Analyze the current state, past observations, and the original prompt to decide what to do next.
Act: Execute a command over SSH (or sometimes a local action, but usually SSH).
Observe: Capture the command's stdout, stderr, and exit code.
Repeat: Feed the observation back into the next thinking step.

This loop continues until the model declares the task done or a safety limit is reached. Crucially, the model never sees the SSH credentials or the raw connection; it only proposes commands, which Batuta executes in a controlled environment.

Here's a simplified pseudocode of the loop:

ssh_client = connect_to_server(host, key)
observations = []
for step in range(max_steps):
    thought = model.think(prompt, observations)
    if thought.action == "done":
        break
    if thought.action == "run_command":
        cmd = thought.command
        # Sanitize/validate command (no interactive sessions)
        stdout, stderr, exit_code = ssh_client.execute(cmd)
        observations.append({
            "command": cmd,
            "stdout": stdout,
            "stderr": stderr,
            "exit_code": exit_code
        })
    # Optionally, thought could include "ask_human" for safety

The model can also request file contents, list directories, or even apply patches. But everything goes through SSH exec, not a full terminal, which keeps things predictable and auditable.

Connecting to Cloud VMs

Batuta supports standard SSH authentication: key-based or password (though we recommend keys). When you trigger a Batuta run, you provide the host, user, and key (or reference a stored credential in Orquesta). Batuta establishes a single SSH session and reuses it for all commands, reducing connection overhead.

We also support SSH config files, bastion hosts, and proxies, but for simplicity, here's a basic connection snippet using Paramiko (our Python SSH library):

import paramiko
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect(hostname="my-vm.example.com", username="ubuntu", key_filename="/path/to/key.pem")

Once connected, Batuta runs commands with a timeout (default 30 seconds) and captures output with a max buffer (e.g., 100KB) to prevent hanging or overwhelming the model context.

Real Example: High CPU Usage

Let's see Batuta in action. I'll narrate a real debugging session from a staging server that suddenly spiked to 100% CPU.

Prompt to Batuta: "The server node-1 has high CPU usage. Find the cause and fix it."

Batuta starts by running top, but we've configured it to prefer non-interactive commands first. It actually runs:

ps aux --sort=-%cpu | head -n 10

Output (truncated):

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
ubuntu   12345 98.3  0.5 249876 45678 ?        R    14:32   3:22 /usr/bin/python3 /opt/app/worker.py
ubuntu   12346 50.1  0.4 235678 43210 ?        R    14:32   1:45 /usr/bin/python3 /opt/app/worker.py
...

Batuta's thought: "The process worker.py (PID 12345) is consuming most CPU. It's a Python script in /opt/app. Let's check what it's doing. I'll look at the process command line and open file descriptors."

Next command:

ls -l /proc/12345/fd

Output shows many sockets, indicating network activity. Batuta then runs:

ss -tunap | grep 12345

It sees the process making many connections to an external IP. Aha! Batuta reasons: "This looks like a runaway process making excessive outbound connections, possibly a bug or a fork bomb. I'll check the script's recent logs."

It runs:

tail -n 50 /var/log/worker.log

Logs show repeated errors connecting to a database. Batuta concludes: "The worker is stuck in a retry loop, spawning new connections without backoff. The immediate fix is to kill the process and restart the service to apply a configuration fix."

But before killing, Batuta checks if the service is managed:

systemctl status worker

Then:

systemctl stop worker && kill -9 12345 12346 || true
systemctl start worker

It verifies CPU usage dropped:

ps aux --sort=-%cpu | head -n 5

Now CPU is back to normal. Batuta reports the root cause and actions taken, and in Orquesta's UI, you see a full audit trail of every command and output.

That's a simple case, but it demonstrates the loop: Batuta didn't just run a kill command; it investigated step by step, adapting based on observations.

Real Example: Disk Full

Another common issue: disk space exhaustion. A production database server started throwing "no space left on device" errors.

Prompt: "The DB server db-1 is out of disk space. Find what's taking up space and clean it safely."

Batuta first confirms:

df -h /

Output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   50G   20K 100% /

Then it finds large files:

du -ah / | sort -rh | head -n 20

It discovers a 30GB log file in /var/log/myapp/access.log. Batuta checks if it's safe to truncate:

lsof | grep access.log

No process has it open, so truncation is safe. Batuta decides:

truncate -s 0 /var/log/myapp/access.log

But it's smart enough to also check log rotation. It sees no logrotate config for that file, so it suggests adding one. In the same run, it can create a logrotate entry and restart the logging service. The whole process took less than a minute, whereas a human would spend 10-15 minutes.

Safety and Guardrails

Autonomous action on production servers is scary. That's why Batuta has built-in safety measures:

Command allowlist/denylist: We block destructive commands like rm -rf /, dd, mkfs, etc. by default, but you can customize.
Dry-run mode: Batuta can propose commands without executing, for review.
Human approval: For high-risk actions (e.g., killing processes, deleting files), Batuta can pause and ask for confirmation via the Orquesta UI or Telegram.
Audit trail: Every command, output, and thought is logged and encrypted. You can replay the entire session.
Timeout and max steps: Prevent infinite loops.

We also use ReAct's "think" step to have the model state its reasoning before acting, which helps us audit decisions.

How Batuta Fits into Orquesta

Batuta is one of four execution modes in Orquesta. The others are Auto, SSH, and Agent (Claude CLI). Batuta stands out because it's fully autonomous with a reasoning loop. You can invoke it directly from the Orquesta UI, CLI, API, or even Telegram. It's perfect for routine maintenance, incident response, and one-off fixes.

Because Orquesta runs locally and streams output in real-time, you can watch Batuta's thought process live in the Agent Grid. You're never in the dark.

Limitations and Future Work

Batuta is not a silver bullet. It works best on well-defined issues with accessible logs and standard Linux tools. Complex, multi-service failures may still require human expertise. The model can also be wrong; that's why we emphasize auditability and optional approval steps. We're continually improving the model's reasoning and expanding the command library.

Takeaway

Batuta AI brings the ReAct loop to server debugging. It's not magic; it's a disciplined process of think, act, observe, repeat, constrained by SSH and safety guardrails. We've used it to cut down MTTR for common issues from hours to minutes. If you manage cloud VMs, this is the kind of automation that actually saves time without sacrificing control.

CLAUDE.md Sync: Enforcing Coding Standards on AI Agents

Orquesta𝄢 — Sun, 25 Oct 2026 12:00:54 +0000

Originally published at getorquesta.com/blog/claude-md-sync-enforcing-coding-standards-ai-agents

When we first started using AI agents to write code across our team, the output was wildly inconsistent. One developer's agent would produce perfectly formatted TypeScript with strict null checks, while another's would generate Python-style variable names in a JavaScript project. The root cause wasn't the model—it was the instructions. Each machine had a different CLAUDE.md file, or none at all.

CLAUDE.md is the configuration file that Claude Code (Anthropic's CLI) reads to understand project-specific rules, conventions, and expectations. It's a simple markdown file that sits in the project root and gets injected into the agent's context on every run. But when you have a team of developers all running agents locally, keeping that file consistent becomes a nightmare. Git can version it, but developers forget to pull, or they override it with personal tweaks. The result: agents drift apart, and code reviews become a war of style nitpicks instead of substance.

We built Orquesta to solve this problem at the infrastructure level. The idea is simple: write your coding standards once in a central dashboard, and have them automatically synced to every agent execution—no matter who runs the agent or on what machine. We call it CLAUDE.md Sync, and it's the single most important feature for making AI agents work consistently across a team.

Why a Centralized CLAUDE.md Matters

AI agents are only as good as their instructions. If two agents receive different versions of CLAUDE.md, they will produce different code styles, use different libraries, and even follow different architectural patterns. This creates merge conflicts, increases review time, and erodes trust in the AI-generated output.

The naive approach is to put CLAUDE.md in a shared repository and hope everyone keeps it updated. But that fails in practice:

Developers clone the repo, then modify CLAUDE.md locally for a specific task and forget to push.
New team members start with an outdated version until they remember to pull.
Contractors or external contributors may not have access to the internal repo where the canonical file lives.
CI/CD pipelines can enforce linters, but the agent's own decision-making is already influenced by the stale instructions.

Orquesta's sync eliminates these failure points by treating CLAUDE.md as a managed configuration, not a file that lives in the project.

How Orquesta Implements CLAUDE.md Sync

The workflow is straightforward from the user's perspective:

A team lead or senior developer writes the coding standards in the Orquesta dashboard. This could be anything from naming conventions to mandatory error handling patterns.
The platform stores the content securely (AES-256 encrypted at rest) and associates it with the team or specific projects.
When any team member launches an agent via Orquesta—whether through the web UI, CLI, or Telegram bot—the system automatically injects the latest CLAUDE.md into the agent's context before execution begins.

Under the hood, the Orquesta CLI handles the sync. When you run an agent locally, the CLI first checks the dashboard for the current version of CLAUDE.md and writes it to the expected location in your project (e.g., ./CLAUDE.md). This happens transparently in milliseconds, so you're always working with the most recent rules.

Here's what the sync looks like from the command line:

# Run an agent with Orquesta CLI
orquesta run "Refactor the auth service to use JWT"

# Behind the scenes:
# 1. CLI fetches latest CLAUDE.md from dashboard
# 2. Writes to ./CLAUDE.md (or appends to existing)
# 3. Executes Claude Code with that file in context

If you prefer to manage the sync programmatically, the Orquesta API provides an endpoint:

curl -X GET https://api.getorquesta.com/v1/claude-md \
  -H "Authorization: Bearer $ORQUESTA_TOKEN" \
  -o CLAUDE.md

The dashboard itself offers a real-time editor with version history, so changes are tracked and can be rolled back if needed.

Enforcing Standards Across Every Agent Run

The real power of CLAUDE.md Sync emerges when you combine it with Orquesta's execution modes. Whether you're using the Agent mode (which invokes Claude CLI directly), Batuta mode (our autonomous SSH agent with a ReAct loop), or even SSH mode for manual commands, the same CLAUDE.md is applied because the sync happens before any execution begins.

We also integrated the sync with our quality gates. Before a real change is committed, the AI simulates the modification and presents a diff. The team lead can review the diff against the coding standards defined in CLAUDE.md. If the agent violated a rule, the lead rejects the change, and the agent can be re-run with the same instructions. This creates a feedback loop where the standards are enforced not just by the agent's own adherence but also by human oversight.

A Concrete Example: Standardizing TypeScript Strictness

Let's walk through a realistic scenario. Your team decides that all TypeScript code must use strict mode, avoid any, and follow a specific import order (external modules first, then internal). Previously, you'd have to:

Update CLAUDE.md in your repo.
Ask every developer to pull the latest and restart their agents.
Hope the agents actually follow the new rules.

With Orquesta, the team lead opens the dashboard, edits the CLAUDE.md content, and saves. The change takes effect immediately for all future agent runs. No one needs to remember to update anything locally—the sync is automatic.

Here's a snippet of what that CLAUDE.md might look like in the dashboard:

# Project Coding Standards

## TypeScript
- Always enable `strict` in tsconfig.json.
- Never use `any`. Use `unknown` and narrow types.
- Imports must be ordered: external packages first, then relative imports.
- Use function declarations instead of arrow functions for top-level components.

## Error Handling
- All async functions must have try/catch blocks.
- Use custom error classes extending `Error`.

## Naming
- Variables: camelCase
- Classes: PascalCase
- Constants: UPPER_SNAKE_CASE for truly constant values only.

Once saved, every agent—whether run by a junior developer on their laptop or by the CI integration—will receive this exact content.

Overcoming the "Local Environment" Challenge

One might argue that you could just use a git submodule or a shared symlink to distribute CLAUDE.md. But those approaches break down when agents run in different directories, or when you want to enforce different rules for different projects. Orquesta's sync is context-aware: you can define a global CLAUDE.md for the entire organization, and optionally override it per project. The CLI merges them intelligently, with project-specific rules taking precedence.

We also made sure the sync works offline. If the dashboard is unreachable, the CLI falls back to the last cached version, so agents don't fail. But in practice, the dashboard is always available, and the sync adds negligible latency.

Security and Auditability

Because Orquesta agents run on your own machine (not in a cloud sandbox), the CLAUDE.md sync happens over an encrypted channel, and the content never leaves your infrastructure in an insecure way. The dashboard stores the file encrypted at rest, and each sync is logged in the audit trail alongside prompts, logs, and diffs. This means you can always see which version of CLAUDE.md was active for any given agent execution, which is invaluable for debugging unexpected behavior.

What We Learned Building This

The biggest surprise was how quickly teams adopted the sync once they realized the impact. Initially, we thought developers would resist having their instructions controlled centrally. But the opposite happened: they welcomed it because it removed ambiguity. No more debates about tabs vs. spaces—the standard is written once and enforced everywhere.

We also found that syncing CLAUDE.md reduced the time spent on code review by roughly 30% in our own usage, because the agents produced code that already matched our style. That freed reviewers to focus on architecture and logic instead of formatting.

The Takeaway

CLAUDE.md Sync is more than a convenience feature—it's the glue that makes AI agents a reliable part of a team's workflow. By centralizing coding standards and automatically applying them to every execution, you eliminate inconsistency, reduce review overhead, and create a single source of truth for how AI should write code. If you're serious about using AI agents in production, treat your CLAUDE.md like infrastructure: managed, versioned, and synced automatically. Orquesta does exactly that.

Git-Native AI Development: Every Action is a Commit

Orquesta𝄢 — Fri, 23 Oct 2026 12:01:11 +0000

Originally published at getorquesta.com/blog/git-native-ai-development-every-action-is-a-commit-2026-10-23

We built Orquesta with a core assumption: when an AI agent modifies your codebase, you need the same level of traceability you'd expect from a human developer. That means every change lands as a discrete commit, with a diff, an author, and a timestamp. No ephemeral patches, no hidden state. Just git.

Most AI coding tools today treat the repository as a sandbox for experimentation. The agent might apply changes directly to the working tree, or maybe create a single mega-commit at the end of a session. Both approaches obscure the decision-making process. When you review the code later, you can't tell which file was touched by the agent at which step, or why. Rollback becomes a binary choice: accept everything or revert everything. That's a dangerous place to be when you're letting an LLM drive.

Our approach is different. In Orquesta, the agent operates on real branches, and every atomic action it takes becomes a git commit. When the agent edits a file, runs a command, or even just thinks about something in Batuta mode, we snapshot the repository state with a clear commit message. The result is a chronological, auditable log of everything the AI did.

Why traditional AI coding falls short

Let's be honest about the current landscape. Tools like Copilot or ChatGPT generate code snippets, but you copy-paste them yourself. You're the one making the commit. More autonomous agents, like Devin or OpenHands, operate in cloud sandboxes and push changes to your repo at the end of a task. But the intermediate steps are often lost or compressed into a single commit with a generic message like "AI refactor". That's not traceability, it's a black box with a receipt.

When you're working in a team, especially with production code, you need to answer questions like:

What exactly did the AI change in this file?
When did it make that change relative to other modifications?
Who authorized this change? Was it the AI acting autonomously, or a human approving a step?
If something breaks, how do I isolate and revert only the problematic part?

Without granular commits, these questions are hard to answer. You end up bisecting manually or reading through the entire diff of a large commit, hoping to spot the issue. That's wasted engineering time.

Implementing git-native AI actions

In Orquesta, we treat the git repository as the source of truth for the agent's activity. When you submit a prompt, the agent starts working in a dedicated branch. Every time the agent performs a discrete action—creating a file, editing a block, running a shell command that modifies the code, or even running a test and fixing a failure—we automatically commit the changes. The commit message is generated by the agent itself, summarizing what it did and why. For example:

git log --oneline -5
a3f2c1d (HEAD -> feature/agent-refactor) fix: update regex pattern to handle edge case
8b7e6f5 test: add unit test for new validation logic
c2d9a4e refactor: extract helper function to reduce duplication
7e1b3c0 docs: update README with new API details
5f8d2a1 initial: scaffold new module structure

Each commit has a clear, human-readable message. The author field is set to the AI agent's identity, not the human user, so you can distinguish who (or what) made each change. In our case, we use a separate git config for the agent, like user.name "Orquesta Agent" and user.email "agent@orquesta.local". This separation is crucial for accountability: if something goes wrong, you know it wasn't your teammate's manual edit—it was the machine.

We also ensure that the agent doesn't work directly on main or shared branches. It creates a feature branch from the base. Then, when the work is done, you can open a pull request. The PR shows the complete sequence of commits, allowing reviewers to see the evolution of the code, not just the final state. They can comment on individual commits, ask for changes, or revert specific ones if needed.

The power of step-by-step rollback

The biggest benefit of this approach is surgical rollback. Imagine the agent is working on two separate features in the same session: adding a new API endpoint and fixing a bug in an unrelated utility. Without discrete commits, if the API endpoint introduces a regression, you'd have to revert the entire session's work to remove it, losing the bug fix too. With granular commits, you can simply:

git revert a3f2c1d

and only the problematic commit is undone, leaving the rest of the work intact.

This also helps when you want to experiment with different approaches. Since each step is a commit, you can branch off from any point in the agent's history, cherry-pick specific changes, or compare two alternative paths. It's like having a time machine for your codebase, powered by git's own mechanics.

We've used this to great effect internally. During a recent refactor of our CLI, the agent made a series of commits that progressively improved the code. When we later realized that an early optimization actually made things slower, we were able to git revert that single commit without touching the dozens of subsequent improvements. That would have been a nightmare with a single mega-commit.

Handling commit noise

One common objection is that committing every action creates too much noise. If the agent makes 50 tiny edits, you get 50 commits, cluttering the history. We've addressed this in two ways. First, the agent is instructed to combine related changes into a single commit when appropriate. For example, if it's fixing a typo across multiple files as part of a single logical change, that becomes one commit. Second, we provide a post-processing step in Orquesta where you can squash commits before merging. This gives you the best of both worlds: during the agent's execution, you see every step in real-time, but the final merged history can be as clean as you want.

It's also worth noting that these intermediate commits are on the agent's feature branch, not on your main branch. So the noise is contained. Once you're satisfied, you can squash-merge the entire PR into a single clean commit if that's your team's preference. The granularity is still there for the review process.

Security and auditability

Since Orquesta runs the agent locally on your machine (or on your own infrastructure via Batuta over SSH), the git commits are created locally. No code is pushed to a third-party cloud sandbox. That means your commit history stays within your control. For regulated industries, this is a significant advantage—you can demonstrate exactly what the AI did, when, and with what authorization, all from your existing git logs. Combined with our full audit trail of prompts and API calls, you have a complete chain of custody.

What about non-code actions?

You might wonder: the agent might run commands that don't modify files, like checking the current git status or running a build to see if it passes. Should those be commits? In Orquesta, we only create commits when the repository state changes. Commands that are read-only don't generate commits because there's nothing to commit. But we do log them in the agent's activity feed, so you can see what the agent was doing between commits. This keeps the git history focused on actual changes.

Conclusion

Making every AI action a git commit is more than a technical gimmick. It's a philosophical stance: if we're going to let machines write our code, we need to hold them to the same standards of traceability and accountability that we expect from human developers. Git is the perfect tool for this—it's battle-tested, universally understood, and already integrated into every developer's workflow. By building Orquesta on git-native principles, we've turned AI from a black box into a transparent collaborator. And when something goes wrong, as it inevitably will, you'll be glad you can see every step it took.

Agent Grid: Monitor Dozens of AI Agents From One Screen

Orquesta𝄢 — Wed, 21 Oct 2026 12:00:54 +0000

Originally published at getorquesta.com/blog/agent-grid-monitor-dozens-ai-agents

The Terminal Sprawl Problem

When we first started running AI agents for code generation, we were fine with a handful of terminal tabs. Each agent ran claude or gpt in a separate tmux pane, and we'd flip between them. That worked until we had ten agents running across different repositories, each on its own feature branch, with different prompts and execution modes. Suddenly, we were spending more time finding the right terminal than actually reviewing the code the agents produced.

Terminal multiplexers like tmux and screen are great for command-line work, but they don't understand what an AI agent is doing. They show raw output but no context: which agent is stuck, which one just opened a PR, which one is burning through tokens on a bad loop. We needed a monitoring tool built specifically for AI agents, not a generic terminal manager.

That's why we built Agent Grid. It's a single dashboard that shows every AI agent running on your machine, with live streaming terminals, status indicators, and layout controls that make it feel like a mission control for code generation. Here's how it works under the hood and why it matters when you scale to dozens of agents.

How Agent Grid Works

Agent Grid is part of the Orquesta platform. It connects to the Orquesta CLI, which manages local LLM execution (Claude, OpenAI, Ollama, vLLM) and syncs agent state to the dashboard. The Grid itself is a web interface served from a local server, so all data stays on your machine. No cloud round-trips, no latency, and your code never leaves your infrastructure.

The core components are:

Live Terminals with Streaming Output

Each agent appears as a tile in the grid. Inside that tile, you see a live terminal stream—every line the agent prints, every tool call, every git commit message. The stream updates in real-time via a WebSocket connection to the local Orquesta server. We use xterm.js for terminal rendering, which gives us full ANSI escape code support, so colors and formatting from the underlying CLI are preserved.

You can click any tile to expand it to a full-screen terminal, or keep it in the grid for a glanceable view. The expanded view also gives you access to the agent's full history, not just the current session. That's critical when you need to debug why an agent entered a retry loop or made a questionable edit.

Drag-to-Rearrange and Layout Persistence

Tiles are draggable. You can reorder them, resize them, and create custom column layouts. If you're running five agents on the frontend and three on the backend, you can group them visually. The layout persists across sessions, so every time you open Orquesta, your grid is exactly how you left it.

We built this with a simple grid system using CSS Grid under the hood, but we added drag-and-drop with react-dnd. Each tile has a unique agent ID, and the layout state is stored in a local JSON file. This means you can have different layouts for different projects—define a layout per workspace, and Orquesta will load it automatically when you cd into that directory.

Status Indicators for At-a-Glance Monitoring

The most important part of monitoring multiple agents is knowing which ones need your attention. Each tile has a status badge in the corner:

Green: Agent is running and making progress.
Yellow: Agent is waiting for input or an external resource (like a code review).
Red: Agent has errored out or exceeded a token limit.
Gray: Agent is paused or completed.
Blue: Agent is in Batuta mode (autonomous ReAct loop).

These colors are consistent across the Orquesta UI, so you can spot a failing agent from across the room. We also show a small progress indicator—a thin bar that fills based on the estimated steps remaining. It's not perfect, but it gives you a sense of whether an agent is 10% or 90% done without opening the terminal.

Column Layouts and Responsive Resizing

The Grid supports multiple column modes: 1, 2, 3, 4, or auto. Auto mode uses a CSS masonry-like layout that fits as many tiles as possible based on your screen width. On a 4K monitor, you can comfortably view 16 agents in a 4x4 grid. On a laptop, auto mode stacks them vertically but keeps the live terminal streams scrolling.

We also added a "focus mode" that temporarily hides all other tiles and gives the selected agent the full screen. It's like zooming in on one agent without losing the context of the others. A quick keyboard shortcut (Ctrl+F) toggles it.

Why This Matters When You Run 10+ Agents

Running one or two AI agents is manageable. Running ten, twenty, or fifty is a different beast. The problems compound quickly:

Context switching: Each agent has its own prompt, branch, and execution mode. You need to remember what each one is supposed to do.
Error detection: If an agent silently fails and you don't notice, you might merge broken code.
Resource usage: Multiple local LLM processes (especially vLLM) can eat RAM and GPU. You need to see which agent is hogging resources.
Parallel development: When you have agents working on different features, you want to review their diffs as they come in, not after the fact.

Agent Grid solves these by giving you a single plane of glass. You can see all agents, their status, and their live output at once. No more alt-tabbing through terminals or running ps aux | grep claude to find a stuck process.

A Real Workflow: Running 12 Agents Across 3 Projects

Here's a typical scenario we use internally. We have three repositories: a backend service, a frontend app, and a shared library. We spin up four agents per repo:

orquesta agent start --prompt "Refactor the auth module to use JWT" --mode auto --repo backend
orquesta agent start --prompt "Add rate limiting middleware" --mode batuta --repo backend
orquesta agent start --prompt "Implement a new dashboard component" --mode agent --repo frontend
orquesta agent start --prompt "Fix failing tests in the billing service" --mode ssh --repo backend

Each command launches an agent and registers it with the Grid. The Grid tiles show the agent's mode, the repo, the current git branch, and a live stream of its actions. If one of the Batuta agents starts looping (e.g., it keeps trying to fix a bug that isn't there), the status indicator turns red, and we can click into the terminal to see the ReAct loop: Think > Act > Observe > Repeat. From there, we can intervene manually or kill the agent.

After a few minutes, agents start opening PRs. The Grid shows a small notification badge on the tile when a PR is created. We can then review each PR in a side panel without leaving the Grid.

Resource Monitoring Integration

One feature we added early was CPU and memory usage per agent. Each tile shows a tiny sparkline of the agent's resource consumption. When you're running local models with Ollama or vLLM, this is invaluable. You can spot a memory leak in a model server before it takes down your whole machine.

Under the Hood: How the Grid Stays in Sync

The Orquesta CLI runs a local WebSocket server on port 7373. Each agent process communicates with this server to send its output and status. The Grid web UI connects to the same server and receives updates in real-time. Because everything is local, latency is under 10ms—essentially instant.

We deliberately avoided polling. Polling would add unnecessary CPU load and introduce lag. WebSockets give us a push model that scales to dozens of agents without breaking a sweat.

The Grid UI is built with React and TypeScript. We use Zustand for state management, which keeps the component tree lean even with 50+ tiles. Each tile is memoized, so only the active terminal stream re-renders on each update. That's crucial for performance—when you have 20 agents all streaming output at 60 lines per second, you don't want to re-render the entire grid every 16ms.

The Future of Agent Grid

We're currently working on a few enhancements:

Group actions: Select multiple agents and pause, resume, or kill them in one click.
Search and filter: Quickly find an agent by prompt keyword, repo, or branch.
Notification hooks: Send a Slack message or email when an agent fails or opens a PR.
Cross-machine monitoring: Use Orquesta's cloud sync to view agents running on remote servers via SSH (already possible with Batuta, but we want it in the Grid).

Takeaway

Agent Grid isn't just a terminal multiplexer with a facelift. It's a purpose-built monitoring tool for AI agents, designed to handle the chaos of running dozens of code-generating processes simultaneously. The combination of live terminals, drag-and-drop layouts, status indicators, and column modes makes it possible to manage a fleet of agents without losing your sanity. If you're running more than five AI agents on your machine, you need something like this—and if you're using Orquesta, you already have it.

Quality Gates: Keeping AI Agents Productive Without Going YOLO

Orquesta𝄢 — Mon, 19 Oct 2026 12:01:21 +0000

Originally published at getorquesta.com/blog/quality-gates-keeping-ai-agents-productive-without-going-yolo

We built Orquesta to let teams turn prompts into code, PRs, and deployments. But letting an AI agent loose on your codebase with full autonomy is a recipe for disaster. The tension is real: you want the speed of autonomous execution, but you need control over what gets changed. That's where quality gates come in. They let the agent run at full speed, simulate the changes, and present a diff for human approval before anything touches the real environment.

The Tension Between Autonomy and Control

When we first started building Orquesta, we gave the agent full run of the repo. It was fast—sometimes too fast. It would refactor entire modules, add dependencies we didn't want, or "fix" things that weren't broken. The output was impressive, but reviewing the aftermath was like cleaning up after a hurricane. We needed a way to keep that speed while adding a checkpoint that didn't grind everything to a halt.

The naive solution is to have the agent explain every step and wait for approval. That kills the momentum. Nobody wants to click "approve" on every file write. The better approach is to let the agent do its thing in a simulated environment, produce a complete set of changes, and then have a human review the final diff. That's exactly what quality gates do.

How Quality Gates Work in Orquesta

In Orquesta, a quality gate is a configurable step in the agent's execution pipeline. When enabled, the agent runs in "simulation mode." It has full access to the repository, but instead of committing directly to the main branch, it creates a set of proposed changes—essentially a patch or a series of commits on a feature branch. The agent streams its output as usual, but the real git history isn't touched.

Once the agent finishes, the generated diff is presented for review. A designated reviewer—usually a team lead or senior engineer—can inspect the changes, comment, and either approve or reject. If approved, the changes are applied to the real branch and merged. If rejected, they're discarded, and the agent can be re-prompted with feedback.

This flow is similar to how pull requests work, but the key difference is that the agent produced the entire change set autonomously before any human looked at it. The human only reviews the final result, not the intermediate steps. This gives you the speed of autonomy with the safety of a review gate.

Simulation Mode: The Technical Details

The trickiest part was building a simulation mode that feels real to the agent but doesn't modify the actual repository. We handle this by running the agent in a git worktree. A worktree is a separate working directory linked to the same repository, so the agent can make changes, run tests, and even commit locally without affecting the main checkout. When the agent finishes, we compare the worktree's branch with the base branch to generate a diff.

# Create a new worktree for the agent's run
git worktree add ../agent-run-123 -b agent/feature-123

# Agent runs inside ../agent-run-123, making commits as it goes

# After the agent completes, generate the diff
git diff main...agent/feature-123 > changes.patch

The patch is then shown in the Orquesta dashboard as a standard PR-style diff. The reviewer can see file changes, additions, deletions, and even the commit messages the agent used. The agent's own commit messages often provide useful context, but we don't rely on them for approval—the code is what matters.

One important detail: the agent's simulation mode still respects your CLAUDE.md sync. That means coding standards and project conventions are enforced even during simulated runs, so the diff you review already follows your team's rules. No surprises.

Configuring Quality Gates

We made quality gates flexible because different teams have different risk tolerances. In Orquesta, you can configure:

Who can approve: specific users or roles.
Required approvals: one or more.
Scope: gates can apply to all prompts or only those touching certain files (e.g., production code vs. documentation).
Auto-merge: if the gate passes, should the changes be applied automatically or wait for a manual merge?
Timeout: if no one reviews within a set time, the changes expire.

For teams that want even more control, we support multiple gates: one for code review, one for security scanning, one for cost approval, etc. But the core value is the simulation-review-apply loop.

A Real Workflow

Here's how it plays out in practice. A developer submits a prompt: "Fix the login bug where users can't reset passwords." The agent picks up the prompt, spins up a worktree, and starts working. It streams its terminal output to the Orquesta dashboard, so the team can watch if they want, but nobody has to intervene. After a few minutes, the agent has made several commits: updated the auth service, added a test, and fixed a typo in the docs.

The agent then opens a quality gate. The diff appears in the dashboard with all changes. A team lead glances at it: the auth service change looks correct, the test is reasonable, but the docs change is unnecessary. They leave a comment: "Remove the docs change and re-run." The agent picks up the feedback, removes the docs commit, and re-submits. This time the lead approves. The changes are merged to main, and the agent automatically creates a PR for the remaining steps (like deployment) if configured.

That's the speed of autonomy with a human checkpoint. The developer who submitted the prompt never had to write a line of code. The team lead spent maybe two minutes reviewing. The agent did the heavy lifting.

Why Quality Gates Beat YOLO Mode

Fully autonomous mode—what we call "YOLO mode"—is tempting. You set the agent loose and hope for the best. But in practice, it only works for trivial tasks or when you're willing to accept frequent breakage. Quality gates give you a middle ground. The agent still moves fast, but you're not betting the farm on every run.

There's a psychological benefit too. When people know they'll review the final diff, they're more willing to let the agent try ambitious changes. That leads to better outcomes because the agent isn't constrained by fear of breaking things. It can refactor, experiment, and propose bold solutions, knowing that a human will catch any problems.

The Cost of Review

Of course, quality gates aren't free. Someone has to do the reviewing. But we've found that the review burden is much lower than reviewing the agent's step-by-step actions. A typical agent run produces a diff of 50–200 lines. That's a five-minute review. Compare that to pair programming with the agent or manually executing each step—quality gates are far more efficient.

To further reduce fatigue, we're experimenting with AI-assisted review: an LLM that summarizes the diff and highlights risky changes before a human looks at it. But the human is still the final decision-maker.

Conclusion

Quality gates have become the default for most Orquesta teams. They give you the speed of autonomous AI agents without the recklessness. The agent simulates changes, a human reviews the diff, and only then does the code hit the real branch. It's not about slowing down the AI; it's about building trust. Once that trust exists, you can gradually loosen the gates for low-risk tasks and keep them tight for critical paths.

The next time you're tempted to let an AI agent run wild, try a quality gate instead. You might be surprised how fast and safe it feels.

Collaborate Without SSH: A Safer Way to Share Your Dev Environment

Orquesta𝄢 — Sat, 17 Oct 2026 12:01:00 +0000

Originally published at getorquesta.com/blog/collaborate-without-ssh-safer-way-share-dev-environment

The SSH Sharing Problem

Giving someone SSH access to your machine feels like handing over the keys to your house. You trust them not to accidentally rm -rf the wrong directory, not to peek at your .env files, and not to leave your server exposed. But even with the best intentions, things go wrong. Permissions are too broad, keys get shared insecurely, and suddenly your production database is one fat-fingered command away from disaster.

We built Orquesta because we were tired of this trade-off. We wanted a way for teammates—developers, designers, product managers, even non-technical stakeholders—to work in our environment without ever getting shell access. No SSH keys, no terminal sessions, no direct infrastructure access. Instead, they submit prompts, and an AI agent does the work on our behalf, under our supervision.

The New Collaboration Model: Agent-as-Intermediary

The core idea is simple: install an agent on your machine, invite people to your workspace, and let them submit prompts from a web dashboard. The agent—running locally as a CLI tool—executes those prompts using your environment, your credentials, and your context. But the person submitting the prompt never sees your secrets, never gets a shell, and never touches your infrastructure directly. They only see the output stream and the resulting git commits.

This flips the traditional remote work model. Instead of granting access to a whole system, you grant access to a specific capability: the ability to ask an AI agent to perform a task. The agent becomes the intermediary that enforces boundaries, logs everything, and ensures changes are reviewable.

How It Works Under the Hood

When you install Orquesta on your machine, it runs a local CLI that manages LLM connections (Claude, OpenAI, Ollama, vLLM) and syncs with our dashboard. You connect your git repositories and define quality gates. Then you invite collaborators by email or link. They log in to the dashboard and see a prompt input box—no terminal, no SSH client.

They type a prompt like: "Update the pricing page to reflect the new enterprise tier, and create a PR." That prompt is sent to your local agent. The agent opens your codebase, makes the changes, and commits them to a new branch. It then opens a pull request. Throughout the process, the collaborator watches a live stream of the agent's terminal output—every command, every file diff, every git operation. But they cannot pause, modify, or inject commands. They can only see and wait for the result.

If you've enabled quality gates, the agent will first simulate the changes in a sandbox, present a diff and a summary to a designated team lead for sign-off, and only then execute on the real environment. This ensures that nothing gets deployed without human review.

The Security Model: No Keys, No Shell, No Problem

The most common question we get is: "But if the agent runs on my machine, doesn't that mean the collaborator can do anything?" The answer is no, because the collaborator never interacts with the agent directly. They only send high-level intents through our dashboard. The agent interprets those intents using its own context and permissions. The collaborator has no way to bypass the agent's constraints—they can't ask it to cat ~/.ssh/id_rsa because the agent is not a shell; it's a task executor with a limited action space.

We've also implemented:

AES-256 encryption for all data in transit and at rest.
Full audit trail: every prompt, log, diff, and cost is recorded and tied to the specific user who submitted it.
Role-based permissions: you can define who can submit prompts, who can approve quality gates, and who has admin access to the agent configuration.
No inbound SSH: the agent polls our servers over HTTPS; it doesn't open any ports on your machine. Your firewall stays closed.

This is fundamentally different from giving out SSH access. With SSH, you're betting that the person won't misuse their privileges. With Orquesta, you're betting that our agent will do what it's told—and you can review every action it takes before it affects your environment.

Real-World Workflow: From Prompt to PR Without a Terminal

Let's walk through a concrete example. Sarah, a product manager, wants to update the onboarding flow. She's not technical and has never touched a terminal. With traditional SSH, she'd have to ask a developer to make the changes, or risk being locked out entirely. With Orquesta, she logs into the dashboard and types:

"The onboarding flow currently asks for a phone number, but we no longer need it. Remove that field from the signup form, update the validation logic, and create a PR with a summary of changes."

The agent picks up the prompt, checks out the relevant repository, and starts working. Sarah sees a live feed of the agent's actions:

$ git checkout -b remove-phone-field
$ grep -r "phone" src/
$ sed -i '/phone_number/d' src/signup.html
$ npm test
$ git add .
$ git commit -m "Remove phone number field from signup"
$ git push origin remove-phone-field

She doesn't need to understand any of that. She just sees the PR link appear a few minutes later. The engineering team reviews the PR, leaves comments, and merges it. Sarah never had SSH access, never saw a private key, and never touched the codebase directly. She contributed meaningfully through a controlled interface.

For developers, the same workflow applies but with more complex prompts. Instead of SSHing into a server to debug, they can describe the issue and let the agent investigate, propose fixes, and even deploy—all while they watch from the dashboard. And because every action is a real git commit, the history is clean and reviewable.

Why This Beats SSH for Team Collaboration

SSH was designed for single-user remote administration, not for collaborative development. It has no concept of roles, no audit trail, no approval workflow. It's a blunt instrument. Orquesta's agent-based approach gives you:

Fine-grained access: You can let a designer submit UI change requests without letting them anywhere near your database credentials.
Built-in review: Quality gates simulate changes before they hit your environment, so you can catch mistakes early.
Cross-functional collaboration: Non-technical team members can contribute directly to code changes without learning git or SSH.
Complete visibility: The live stream and audit log mean you always know what the agent did and why.

We're not saying SSH is obsolete—we use it every day for our own work. But for sharing your environment with others, it's the wrong tool. It lacks the controls that modern teams need.

Getting Started: Install, Invite, Delegate

To set this up in your own team, you install the Orquesta CLI on a machine that has access to your repositories and environment. It's a one-liner:

curl -fsSL https://get.orquesta.dev | sh
orquesta init
orquesta connect

Then you invite teammates from the dashboard. They don't need to install anything—they just need a browser or our Telegram bot. They submit prompts, and your local agent does the work.

You can also configure CLAUDE.md files to enforce coding standards, so the agent always follows your team's conventions. And if you want to scale, the Agent Grid lets you monitor multiple agents from one screen, each with its own live terminal.

The Takeaway

The old way of collaborating on a shared environment—SSH keys and terminal sessions—creates more risk than it solves. It's insecure, opaque, and exclusionary. The new way is to let an AI agent act as a trusted intermediary: it runs on your machine with your permissions, but it only does what your collaborators ask through a controlled interface. They get the work done without ever seeing your keys or touching your infra. That's the future of team collaboration, and we've built it into Orquesta.

CLAUDE.md Sync: Standardizing AI Agent Coding Standards

Orquesta𝄢 — Thu, 15 Oct 2026 12:01:48 +0000

Originally published at getorquesta.com/blog/claude-md-sync-standardizing-ai-agent-coding-standards

I remember the first time a team told me their AI agents were producing code that looked like it came from five different developers. It did—because it had. Each engineer had their own local CLAUDE.md file, if they had one at all. Some were outdated, some were overly permissive, and most were missing entirely. The result was a mess: PRs with inconsistent formatting, missing tests, and architecture decisions that contradicted each other.

We built Orquesta to solve this exact problem. The platform runs AI agents locally on your machine, streams output in real-time, and turns every action into a real git commit. But the key to making those agents work consistently across a team isn't just the agent runtime—it's how you configure them. And for Claude Code, the configuration that matters most is CLAUDE.md.

The Problem: Agents That Drift

Claude Code reads a file called CLAUDE.md from the root of your project. It's like a README for the AI: it contains instructions, preferences, and rules that Claude should follow while working in that repository. For example:

# Project Instructions
- Use TypeScript strict mode in all new files.
- Prefer functional components over class components in React.
- Write unit tests for every new utility function.
- Follow the conventional commits specification (feat:, fix:, chore:).
- Do not introduce new dependencies without approval.

That's powerful, but it only works if every engineer on the team has the same CLAUDE.md. In practice, that rarely happens. Developers copy files from old projects, forget to update them, or don't create one at all. The AI agent then defaults to generic behavior, which may not match team expectations. The result is code that passes syntax checks but fails architectural review, or commits that break the team's commit message format.

Even worse, when a new developer joins, they have to manually configure their local environment to match the team's standards. That's time wasted and a source of frustration. And if a team lead updates a standard, everyone has to update their local files manually. It's the same problem we solved years ago with linters and formatters, but for AI agent instructions.

What CLAUDE.md Actually Is

Before we get to the solution, let's be precise. CLAUDE.md is not a magic file; it's a plain Markdown file that Claude Code automatically reads and treats as system-level instructions for the project. It can include anything: coding conventions, architectural notes, testing requirements, deployment constraints, or even team-specific preferences like "always use async/await instead of promises."

The file sits in your repository root, so it's version-controlled. But that's also part of the problem: multiple teams might work in the same repo, each wanting different instructions. Or you might have multiple repositories with different needs. A single CLAUDE.md per repo isn't flexible enough for larger organizations.

That's why we decided to make CLAUDE.md sync a first-class feature in Orquesta.

Centralizing Standards with Orquesta

Orquesta provides a dashboard where you can write and manage CLAUDE.md files for your entire team. Instead of each developer maintaining their own local copy, you define the rules once in the dashboard, and Orquesta ensures that every agent execution on any machine uses the exact same version.

Here's how it works:

A team lead (or someone with the right permissions) writes a CLAUDE.md file in the Orquesta dashboard. They can use the built-in editor with Markdown support, or copy-paste from an existing repo.
Orquesta stores this file securely, versioned, with a full history of changes. You can see who changed what and when.
When any team member launches an agent in Orquesta—whether through the web interface, the CLI, or the Telegram bot—the platform automatically fetches the latest CLAUDE.md and writes it into the agent's working directory before Claude Code starts.
The agent then uses that file as its instruction set. Every prompt, every code generation, every refactor respects the rules defined in the dashboard.

This means that if you update a rule in the dashboard, every subsequent agent execution across your entire team uses the new rule immediately. No manual distribution, no stale local files, no drift.

Technical Implementation: How Sync Works

Under the hood, we added a step in the agent bootstrap process. When an agent is about to start, Orquesta checks the dashboard for the latest CLAUDE.md version. If the local file doesn't exist or is different, we fetch the new content and write it to the agent's temporary working directory (not the user's repo, but the isolated environment where the agent runs). We also validate that the file is valid Markdown and doesn't contain any disallowed characters.

The sync happens over an encrypted connection, and we cache the file locally to avoid repeated network calls. We also include the version hash in the agent's audit log, so you can trace exactly which CLAUDE.md version was active during any execution. That's critical for debugging and for post-mortems.

For teams that already have a CLAUDE.md in their repository, we offer two modes:

Override mode: The dashboard version always wins. Useful for enforcing company-wide standards.
Merge mode: We combine the dashboard rules with the repo's local CLAUDE.md, with the dashboard rules taking precedence on conflicts. This is best for teams that want to keep repo-specific instructions while still enforcing global standards.

We also support multiple CLAUDE.md files for different projects or environments, so you can have a base set of rules for all agents and then layer project-specific instructions on top.

A Concrete Example: Enforcing Commit Conventions

Let's walk through a real scenario. Suppose your team follows strict commit message conventions—every commit must start with a type (feat, fix, chore, etc.) and a scope. You might have a rule in CLAUDE.md like:

Commit messages must follow the conventional commits format:
- Type: feat, fix, chore, docs, style, refactor, test, perf
- Optional scope in parentheses: e.g., feat(auth): add login endpoint
- Subject: imperative, lowercase, no period at the end

With Orquesta's sync, you write that once in the dashboard. Now every AI agent that generates a commit—whether it's fixing a bug, adding a feature, or refactoring code—will automatically format its commit message according to that rule. You don't have to remind the agent in every prompt; the instruction is always present.

The same applies to coding style. If your team prefers function declarations over arrow functions at the top level, or tabs over spaces, or a particular import order, you encode it in CLAUDE.md and it's enforced consistently.

Handling Conflicts and Versioning

One of the trickiest parts of this feature is dealing with conflicts. What if a developer has a local CLAUDE.md that contradicts the dashboard? We decided to make the dashboard the source of truth. Local overrides are possible only if the team lead explicitly allows them in the project settings. That prevents rogue agents from ignoring team standards.

We also needed strong versioning. Every edit to CLAUDE.md in the dashboard creates a new version with an author and timestamp. You can roll back to a previous version if a rule was accidentally broken. And because we log the version in every agent execution, you can see exactly which rules were in effect for any generated code.

Why CLAUDE.md Sync Matters for Scaling AI

As AI agents become part of the daily workflow, consistency becomes non-negotiable. Without a centralized way to manage agent instructions, you'll end up with a chaotic mess: some agents following old rules, others following none, and reviewers spending hours pointing out violations that should have been caught automatically.

CLAUDE.md sync turns those instructions from a personal preference into a team policy. It's the same shift we saw with linters and CI checks—once you enforce standards automatically, code quality improves across the board, and developers can focus on the hard problems instead of nitpicking style.

For us at Orquesta, building this feature was a no-brainer. Our platform already runs agents locally with full transparency, but transparency alone isn't enough. You need control, and control starts with consistent instructions.

The Bottom Line

If you're using Claude Code with a team, you need CLAUDE.md sync. Writing rules once and having them enforced on every agent execution is the only way to scale AI-assisted development without sacrificing quality. Orquesta provides that capability out of the box, along with the audit trail and versioning you need to trust the system.

We built this because we experienced the pain firsthand. Now we're giving it to every team—because the future of software development is humans and AI working together, but only if the AI follows the same rules.

Orquesta CLI: Local LLM Management with Dashboard Sync

Orquesta𝄢 — Tue, 13 Oct 2026 12:01:50 +0000

Originally published at getorquesta.com/blog/orquesta-cli-local-llm-management-with-dashboard-sync

Why Another CLI for LLMs?

Managing LLMs across a team is a mess. Developers want to run models locally for privacy and cost, but collaboration requires shared configuration and visibility. We built Orquesta CLI to bridge that gap: a command-line tool that lets you run any LLM provider locally—Claude, OpenAI, Ollama, vLLM—while syncing every configuration to the Orquesta cloud dashboard. The sync is bidirectional, prompt history is tracked, and tokens are scoped to your organization.

Before Orquesta, our team juggled multiple environment variables, shell scripts, and manual config files. Switching between providers meant editing code or restarting processes. Sharing prompts and model settings happened over Slack or Git. It was fragile.

Orquesta CLI replaces all that with a single binary that understands your local models, manages provider credentials, and keeps the dashboard updated in real time. The agent still runs on your machine—code never leaves your infrastructure—but the control plane lives in the cloud.

Installing and Authenticating

Install the CLI with a single command:

curl -sSL https://get.orquesta.dev | sh

Or via npm:

npm install -g @orquesta/cli

Once installed, authenticate and initialize a project:

orquesta auth login
orquesta init

The auth login command opens a browser for OAuth, creating a local config file at ~/.orquesta/config.yaml. The init command scaffolds a project directory with a .orquesta/ folder containing provider configurations and a connection to your organization's workspace.

The config file uses a simple YAML structure:

org: acme-corp
default_provider: ollama
providers:
  claude:
    api_key: ${CLAUDE_API_KEY}
  openai:
    api_key: ${OPENAI_API_KEY}
  ollama:
    base_url: http://localhost:11434
  vllm:
    base_url: http://localhost:8000
sync:
  bidirectional: true
  interval: 10s

The CLI reads environment variables for sensitive keys, so you never store secrets in plain text. On first run, it generates a machine-specific key pair and registers your device with the dashboard.

Supported Providers

Orquesta CLI supports four provider types out of the box, each with its own advantages:

Claude: Anthropic's API via the claude CLI. Requires an API key. Ideal for code generation and reasoning tasks.
OpenAI: OpenAI's API, including GPT-4 and future models. Also requires an API key.
Ollama: Local model runner that supports Llama, Mistral, and many others. No API key needed; runs entirely on your machine.
vLLM: High-throughput serving engine for production LLM inference. Usually deployed on a GPU server or cluster.

You can configure multiple providers simultaneously and switch between them per prompt or per project.

Managing Local Models with Ollama

Ollama is the easiest way to run models locally. Install it separately, then pull a model:

ollama pull llama3:8b

Orquesta CLI detects the Ollama service and lists available models:

orquesta models list

Output:

Provider: ollama
  llama3:8b
  mistral:7b
  codellama:13b

To set the default model for a project:

orquesta config set provider.ollama.model llama3:8b

The CLI automatically updates the local config and pushes the change to the dashboard. If you have bidirectional sync enabled, any change you make in the dashboard (e.g., switching the team's default model) will be pulled down to your machine within seconds.

Advanced: vLLM for High-Throughput Inference

For teams that need production-scale serving, vLLM integrates seamlessly. Start a vLLM server:

vllm serve meta-llama/Meta-Llama-3-8B --port 8000

Then add it to Orquesta:

orquesta provider add vllm --base-url http://localhost:8000

The CLI will query the vLLM server for available models and register them in the dashboard. You can now submit prompts that route to vLLM, either from the CLI or from the Orquesta web interface. Because vLLM uses continuous batching, throughput is much higher than individual Ollama requests, making it suitable for shared team use.

You can mix providers within a single project. For example, use Ollama for quick local iterations and switch to vLLM when you need to serve multiple teammates concurrently. The CLI handles routing automatically based on the provider you select for each prompt.

Bidirectional Config Sync

The sync engine is the core of Orquesta CLI. Every configuration change—whether from the CLI, the dashboard, or a teammate's action—is propagated to all connected machines. The sync uses a WebSocket connection to the Orquesta cloud, with a local fallback that polls every few seconds if the WebSocket drops.

Changes are versioned and conflict-resolved using a last-write-wins strategy, with a clear audit trail in the dashboard. For example, if a teammate updates the OpenAI API key in the dashboard, it's encrypted and synced to your machine, replacing the old environment variable reference in your local config. Conversely, if you add a new Ollama model locally, that model becomes available to your whole team in the dashboard.

The sync is bidirectional by default, but you can disable it per project if you prefer manual control:

orquesta config set sync.bidirectional false

In that mode, you can still manually push and pull:

orquesta sync push
orquesta sync pull

Prompt History Tracking

Every prompt you submit through Orquesta—whether via the CLI, the dashboard, the Telegram bot, or the embedded SDK—is logged with full context. The CLI records the provider, model, parameters, and the full response. This history is uploaded to the dashboard and associated with your user and organization.

To view recent prompts from the CLI:

orquesta history

Output:

[2024-06-12 14:23:01] user: Generate a Rust function to parse JSON
[2024-06-12 14:23:18] agent: (claude-3-opus) Here's the code...

The dashboard provides a richer view with filters by provider, model, date, and user. You can also see the cost breakdown if using paid APIs. For local models, cost is zero but still tracked for analytics.

This prompt history is crucial for collaboration: teammates can see what prompts were tried, which models performed well, and reuse successful prompts.

Org-Scoped Tokens

Security is a priority. Orquesta CLI uses AES-256 encryption for all data in transit and at rest. API keys are never sent to the dashboard in plaintext; they are encrypted with a key derived from your organization's master key. You can generate scoped tokens for CI/CD or service accounts:

orquesta token create --scope read-only --expires 30d

This produces a token that can be used in headless environments, e.g., in a GitHub Action:

- name: Orquesta sync
  env:
    ORQUESTA_TOKEN: ${{ secrets.ORQUESTA_TOKEN }}
  run: |
    orquesta auth token
    orquesta sync pull

The token grants access only to the specified organization and cannot be used to modify sensitive settings unless granted write scope. All token usage is logged in the audit trail.

A Real Workflow: From Local Model to Team Collaboration

Let's walk through a typical scenario. I'm working on a feature and want to use a local Llama 3 model via Ollama to avoid API costs. I configure Orquesta:

orquesta provider add ollama --base-url http://localhost:11434
orquesta config set provider.ollama.model llama3:8b

This change syncs to the dashboard. My teammate sees that I'm using Llama 3 and decides to try the same model. They run orquesta sync pull and get the config automatically. Now both of us are using the same local model.

I submit a prompt from the CLI:

orquesta prompt 'Refactor this Python function to use async/await'

The prompt is sent to the local Ollama, and the response streams in the terminal. The entire interaction is recorded in the prompt history. My teammate can see my prompt in the dashboard, copy it, and adapt it for their own work.

Later, I want to switch to Claude for a more complex task. I simply change the default provider:

orquesta config set default_provider claude

The CLI automatically loads the Claude API key from the environment and syncs the change. No code changes needed.

Conclusion

Orquesta CLI is not just another wrapper; it's a local-first LLM management tool that respects your infrastructure while enabling team collaboration. By supporting multiple providers, bidirectional sync, prompt history tracking, and org-scoped tokens, it solves the practical problems of running LLMs in a team setting. Whether you're a solo developer or part of a large organization, the CLI gives you control and visibility without sacrificing privacy.

The takeaway: you can run any model locally, keep your data secure, and still collaborate seamlessly with your team through the dashboard. Orquesta CLI makes that possible.

Inside Batuta AI: Autonomous Server Debugging with ReAct Loop

Orquesta𝄢 — Sun, 11 Oct 2026 12:00:44 +0000

Originally published at getorquesta.com/blog/batuta-ai-autonomous-server-debugging

The Problem with Manual Debugging

Every engineer knows the drill: an alert fires, you SSH into a VM, tail logs, run a few commands, stare at stack traces, and eventually find the culprit. Then you fix it, restart the service, and verify. It’s tedious, especially when you’re juggling multiple incidents or it’s 3 AM.

We built Batuta AI to handle this entire loop without human intervention. It’s not a fancy autocomplete or a chatbot—it’s an autonomous agent that connects to your cloud VMs over SSH, reasons about the problem, executes commands, observes results, and iterates until the issue is resolved. Under the hood, it uses a ReAct loop (Think, Act, Observe, Repeat), which we’ve tuned specifically for infrastructure debugging.

The ReAct Loop in Practice

ReAct (Reasoning + Acting) is a prompt engineering pattern where the model first "thinks" about what to do next, then executes an action, observes the output, and uses that observation to decide the next step. Batuta’s implementation is a tight cycle:

Think – The LLM examines the current state (logs, metrics, previous command outputs) and formulates a hypothesis or a specific diagnostic command.
Act – It runs that command on the target server via SSH and captures stdout/stderr, exit code, and timing.
Observe – The output is fed back into the context, along with any new information (file contents, process states).
Repeat – The model either confirms the hypothesis and takes a corrective action, or tries another diagnostic path.

Unlike a simple script that runs a fixed sequence of commands, Batuta can adapt. If a command fails or returns unexpected output, it pivots. If it needs to inspect a file, it reads it. If it needs to restart a service, it does so and then checks health endpoints. This flexibility is what makes autonomous debugging possible.

How Batuta Connects to Your Cloud VMs

Batuta runs on your own machine (or any host you designate) and uses SSH to connect to target servers. You provide SSH credentials or keys via Orquesta’s secure vault—they never leave your infrastructure. The agent does not operate in a cloud sandbox; everything happens locally, with full control over which servers it can access.

A typical Batuta task begins with a natural language prompt, like:

Batuta, debug why the API service on server api-prod-01 is returning 500 errors on the /users endpoint.

The agent then:

Resolves the server name (from your inventory or cloud provider tags).
Establishes an SSH connection using the stored key.
Starts a ReAct loop: it might first check systemctl status api, then tail logs, grep for recent errors, inspect configuration, and so on.

All commands are streamed back to Orquesta’s live terminal, so you can watch the reasoning unfold in real time. If you don’t like a step, you can interrupt and redirect.

Real Example: Debugging a Node.js Crash

Let’s walk through a real incident we reproduced internally. A Node.js service kept crashing with ECONNRESET after a deploy. Here’s the condensed ReAct trace:

Think: The service is failing on outbound HTTP calls. Check recent logs for the stack trace.

Act: journalctl -u api -n 200 --no-pager

Observe: Logs show Error: connect ECONNRESET 10.0.1.15:5432 — a database connection issue.

Think: The database might be unreachable or overloaded. Test connectivity from the server.

Act: nc -zv 10.0.1.15 5432

Observe: Connection refused. The database server isn’t listening on that port.

Think: Check if the database process is running on that host.

Act: ssh db-prod-01 'systemctl status postgresql'

Observe: postgresql.service is active but listening only on localhost. The recent deploy may have overwritten postgresql.conf.

Think: Inspect the configuration file for listen_addresses.

Act: ssh db-prod-01 'grep listen_addresses /etc/postgresql/14/main/postgresql.conf'

Observe: listen_addresses = 'localhost' — it should be * or the private IP.

Think: Fix the configuration and restart PostgreSQL.

Act: ssh db-prod-01 'sed -i "s/listen_addresses = .*/listen_addresses = \'*\'/" /etc/postgresql/14/main/postgresql.conf && systemctl restart postgresql'

Observe: Restart successful.

Think: Verify the API service can now reach the database.

Act: nc -zv 10.0.1.15 5432

Observe: Connection succeeded.

Think: Restart the API service and test the /users endpoint.

Act: systemctl restart api && curl -I http://localhost:3000/users

Observe: HTTP 200. Problem resolved.

Batuta then creates a git commit with the configuration change (if the server is managed via configuration files) and posts a summary to the Orquesta dashboard, including the root cause and the exact commands executed.

Real Example: Resolving a Disk Full Incident

Another classic: a server’s disk fills up, causing writes to fail. Batuta was prompted:

Disk usage is at 98% on worker-02. Find large files and clean up safely.

Here’s the condensed flow:

Think: Check overall disk usage. Act: df -h / → Observe: /var is 96% full.
Think: Drill into /var to find the largest directories. Act: du -sh /var/* | sort -rh | head → Observe: /var/log is 45G, especially /var/log/nginx.
Think: Check for rotated logs older than 7 days. Act: find /var/log/nginx -name "*.gz" -mtime +7 -ls → Observe: Many old access logs gzipped, totaling 30G.
Think: Remove logs older than 7 days, but be careful not to delete current logs. Act: find /var/log/nginx -name "*.gz" -mtime +7 -delete → Observe: 30G freed.
Think: Verify disk usage now. Act: df -h / → Observe: /var down to 55%.
Think: Check if any service depends on those old logs (e.g., log shipping). Act: systemctl status filebeat → Observe: Filebeat is running but logs a warning about missing old logs. It will continue with new logs only.
Think: No further action needed; report summary.

Batuta handled the whole cleanup without human intervention, including the safety check on log shippers.

Multi-Step Reasoning and Edge Cases

Batuta’s ReAct loop excels at multi-step debugging because it maintains a working memory of the investigation. It can chain together commands, conditionally branch, and even ask for clarification if the prompt is ambiguous. For example, if you say "fix the high CPU on prod", Batuta might first identify the process, then check if it’s a known issue, then apply a patch or roll back a recent deploy—all while keeping you informed.

We’ve also built in safeguards: Batuta will not execute destructive commands (rm -rf, DROP TABLE, etc.) without explicit confirmation. You can configure a deny list of commands, and every action is logged with a full audit trail.

Integration with Orquesta

Batuta is one of four execution modes in Orquesta. When you submit a prompt through the web dashboard, CLI, or Telegram bot, you can choose:

Auto – AI picks the best mode (usually Batuta for server tasks).
SSH – Direct one-off command execution.
Agent – Run Claude CLI for code generation and PRs.
Batuta – The autonomous SSH agent described here.

All modes stream output into the Agent Grid, where you can monitor dozens of agents in parallel. Quality gates can be applied: before Batuta makes a change, an AI simulation shows the expected diff, and a team lead can approve or reject. Your CLAUDE.md coding standards are automatically synced to every agent run, ensuring consistent practices.

Security and Audit

Since Batuta operates over SSH, security is paramount. SSH keys are encrypted with AES-256 and stored locally; they never leave your machine. Batuta uses the same SSH config as your local environment, so it respects your ~/.ssh/config and known hosts. Every action—prompt, command, output, diff, cost—is recorded in the audit trail, making it easy to review what the agent did and why.

The Takeaway

Batuta AI turns the tedious cycle of SSH debugging into a well-reasoned, autonomous process. By combining the ReAct loop with direct SSH execution, it can handle multi-step incidents—from diagnosing a crashed service to cleaning up disk space—without human hand-holding. We built it to give engineers back their time and reduce mean time to resolution. It’s not magic; it’s a disciplined loop of thinking, acting, and observing, applied relentlessly until the job is done.

Local Execution: Keeping Code and Credentials on Your Machine

Orquesta𝄢 — Fri, 09 Oct 2026 12:01:39 +0000

Originally published at getorquesta.com/blog/local-execution-keeping-code-and-credentials-on-your-machine

The problem with cloud sandboxes

Most AI coding platforms run agents in managed cloud environments. That means your source code, environment variables, and credentials are copied to a third-party server, processed, and then the results are shipped back. Even if the vendor promises isolation, the reality is that the code left your machine. That's a trust boundary I never wanted to cross.

When we built Orquesta, we made a deliberate decision: the agent runs locally. No cloud sandbox, no remote execution for code generation. The Claude CLI executes on your own machine. It's the same terminal you use every day, with the same SSH keys, .env files, and private repos already configured. We don't need to see your code to help you write it.

Local execution as an architecture, not a feature

Running the agent locally changes the security model fundamentally. Instead of uploading your codebase to a remote environment that could be compromised or subpoenaed, the code never moves. The agent reads files from disk, applies diffs, and commits — all through git on your machine. There is no network hop for source code.

This isn't just about privacy; it's about compliance. If you work in fintech, healthcare, or any regulated industry, sending proprietary code to a third-party sandbox can be a compliance nightmare. With local execution, your existing security controls — VPN, disk encryption, endpoint detection — apply to the entire agent workflow. You don't need to audit a new cloud perimeter because there isn't one.

Credentials stay encrypted, not just secret

Even with local execution, the agent needs to interact with services: GitHub, Jira, Slack, your LLM provider. Many tools store these API keys in plaintext config files or environment variables that get logged accidentally. We chose AES-256 encryption for all credentials stored in Orquesta.

The CLI encrypts secrets before they are written to disk. When the agent needs a token, it decrypts in memory, uses it, and never logs the plaintext. Even if someone exfiltrates your Orquesta config file, they get ciphertext without the key. The key itself is derived from your local machine's secure enclave or a passphrase you control — it never leaves your device.

Here's what that looks like in practice: when you run orquesta login, the CLI generates a local key pair and stores the private key in your OS keychain (macOS Keychain, Windows Credential Manager, or libsecret on Linux). The public key is sent to our server, and all secrets you add via orquesta secrets set are encrypted with that public key before they leave your machine. Our server can store the ciphertext but cannot decrypt it. Only your local agent can.

# Example: adding a GitHub token encrypted locally
orquesta secrets set GITHUB_TOKEN --value ghp_...
# The CLI encrypts with your local public key, then sends ciphertext to Orquesta cloud

Full audit trail: every prompt, every diff, every cost

Security isn't just about encryption; it's about accountability. When an AI agent modifies your codebase, you need to know exactly what changed, who approved it, and why. Orquesta logs every action the agent takes. That includes the original prompt, the full terminal output, every git diff, and the token cost for each LLM call.

These logs are stored with AES-256 encryption at rest and in transit. They are append-only — no one can modify history. For teams, this is invaluable. If a bug is introduced by an agent, you can trace it back to the exact prompt and the exact commit. You can see whether a human reviewed the diff before it was merged, or if the agent ran in Auto mode.

The audit trail also captures metadata: which agent executed the prompt, which execution mode was used, which branch was affected, and how long the run took. This isn't just nice-to-have; it's a requirement for SOC 2 and similar frameworks. We built it in from day one.

Quality gates: human sign-off before real execution

One of the biggest risks with autonomous agents is that they make changes you didn't expect. Orquesta's quality gates address this by simulating changes before they hit your real codebase. When a prompt is submitted, the agent can first generate a plan or a simulated diff. Then a designated team lead reviews it and either approves, rejects, or requests changes.

Only after approval does the agent execute the change for real. This happens in the same local environment, but the human decision is recorded in the audit trail. The result is a workflow that mirrors code review but for AI-generated changes. You get the speed of automation with the control of a traditional PR review.

For example, a junior developer might submit: "Refactor the authentication module to use async/await." The agent runs in Agent mode, produces a diff, and pauses. The team lead reviews the diff in the Orquesta UI, sees that the agent also changed an unrelated test file, and rejects with a comment. The next iteration includes only the intended changes. This loop is fast but safe.

Why we don't use cloud sandboxes, even for compute

Some platforms argue that cloud sandboxes are needed for scale, to run many agents in parallel. We solved that with the Agent Grid. You can monitor dozens of local agents from a single screen, with live terminal streams. Each agent runs on a machine you control — your workstation, a beefy dev server, or a CI runner. The grid aggregates their outputs, costs, and statuses.

This means you can scale to hundreds of agents without ever giving a third party your source code. The compute cost is on your hardware, which is often cheaper than cloud GPU instances for LLM inference. And because the agents run locally, they inherit your network policies: they can only reach the internal services you allow, not arbitrary internet endpoints.

For teams with strict data residency requirements, this is the only viable model. A cloud sandbox in us-east-1 cannot guarantee that data never leaves the region, but a local agent in your Frankfurt office can.

The security model, summarized

Here's what security by default means in Orquesta:

Code never leaves your machine: agent runs locally, git operations stay local.
Credentials encrypted with AES-256: secrets are encrypted before leaving your device; decryption keys never leave your OS keychain.
Full audit trail: every prompt, terminal output, diff, and cost is logged append-only.
Quality gates: AI-simulated changes require team lead approval before real execution.
Local LLM management: Orquesta CLI supports Claude, OpenAI, Ollama, vLLM — you can run fully offline if needed.
No remote execution ever: The platform orchestrates but does not touch your code.

This model isn't for everyone. If you want a zero-setup browser-based agent, you might accept the cloud sandbox tradeoff. But for engineers who care about where their code lives, local execution is the only sane default. We built Orquesta that way because it's what we wanted for ourselves.

What's next

The shift to local AI agents is part of a broader trend: bringing compute back to the edge where the data already lives. With models getting smaller and faster (thanks to quantization and specialized hardware), running an LLM locally is no longer a compromise. It's an advantage.

We're continuing to harden the local execution path: more granular permission controls for what the agent can read and write, signed commits for tamper-evident history, and deeper integration with enterprise identity providers. Security isn't a feature we bolt on; it's the foundation.

Takeaway: If your AI agent needs your source code to do its job, it should run where the source code lives — on your machine, under your control. Cloud sandboxes add a needless trust boundary. Keep the code local, encrypt the credentials, log everything, and make humans sign off before machines make changes. That's security by default.