CLI · PiniShv

CLI Agent Orchestrator: When One AI Agent Isn't Enough

Wed, 05 Nov 2025 00:00:00 +0000

You’ve hit this wall before. You’re working on some complex modernization project with Claude Code or Amazon Q Developer CLI, and the agent starts losing coherence. Too much context. Too many domains. Architecture bleeding into security bleeding into performance optimization. The agent can’t maintain focus.

Your options have been to manually coordinate between separate agent sessions, copying context around like it’s 2010. Or overload one agent with everything and watch quality degrade as the context window fills up.

AWS to the rescue; they just released CLI Agent Orchestrator (CAO): multiple specialized agents working together under a supervisor. Hierarchical orchestration for your AI CLI tools.

It’s early, opinionated, and requires AWS infrastructure. But it shows where developer AI tooling is headed when single agents aren’t enough.

The Problem
#

Single agents work great for focused tasks. Refactoring? Boilerplate? Debugging? Claude Code or Amazon Q handles it.

But try modernizing a legacy mainframe application. Architecture design, security review, performance optimization, testing, data migration. That’s a project spanning multiple disciplines. Load all that context into one agent and watch quality degrade. The agent contradicts itself, forgets earlier decisions, outputs get generic.

The alternative is running separate agents manually. One for architecture. Another for security. Another for performance. Now you’re copying context between them, manually synthesizing outputs, spending more time coordinating than working. You’ve become the orchestration layer.

CAO is AWS’s answer: a supervisor agent manages specialized workers. Each focuses on its domain. The supervisor handles coordination. Configure the team once, let them collaborate.

How It Works
#

A supervisor agent delegates to specialized workers. One for architecture. One for security. One for performance. The supervisor manages sequencing and maintains context. Workers focus on their specialty and report back.

Each agent runs in its own isolated tmux session. No context pollution. The architecture agent’s history doesn’t leak into the security agent’s work. Sessions communicate through Model Context Protocol (MCP) servers, which handle local communication between the isolated sessions, running entirely on your machine.

CAO supports three patterns. Handoff (synchronous): supervisor waits for completion before proceeding. Assign (asynchronous): supervisor delegates and moves on. Send Message: supervisor checks status without blocking. All implemented through Amazon Bedrock action groups.

Example: Mainframe Modernization
#

The supervisor receives “Create a modernization plan for this COBOL banking system.” It hands off sequentially: architecture agent designs the structure, security agent reviews it, then performance and test agents work in parallel. The supervisor synthesizes outputs into a unified plan.

You could apply this to building microservices applications or migrating monoliths. In practice, you’ll iterate on prompts and intervene when agents drift. But the pattern works when configured well.

The Reality Check
#

CAO only works with Amazon Q Developer CLI and Claude Code. Nothing else has shipped despite “future plans” for other tools.

The supervisor runs on Amazon Bedrock, AWS’s managed service for foundation models. You need AWS credentials, Bedrock access, and an AWS account. It’s open source code you can’t run without AWS infrastructure. This is lock-in you should choose consciously.

Everything runs in tmux sessions. Great for transparency, but it’s another dependency with a learning curve. Running this in CI/CD adds complexity.

Multiple agents mean multiple API calls, more token usage, higher latency. For simple tasks, this is wasteful overkill. You need to be selective about when orchestration overhead is worth it.

This is infrastructure for developers comfortable with AWS, tmux, and orchestration concepts. It’s not polished. Limited early reactions on social media praise the privacy focus but flag AWS lock-in and tmux hurdles as barriers to adoption.

Why It Matters
#

The interesting part isn’t CAO specifically. It’s the shift from “AI tool as standalone assistant” to “AI tools as orchestrated teams.”

Single-agent tools hit walls. Context windows don’t solve everything. At some point, more context just means more noise. Multi-agent architectures divide cognitive labor. Each agent has a focused job. The supervisor ensures pieces fit together.

We’re seeing this everywhere. OpenAI’s Swarm. LangGraph. CrewAI. AutoGPT. The underlying idea is the same: complex tasks need coordination, not just more context. Specialization plus orchestration beats generalization with bigger context windows.

The question: does this remain infrastructure developers explicitly configure, or does it become invisible? CAO is clearly “you configure this.” But the long-term direction is probably toward tools that orchestrate automatically, with developers intervening only when defaults fail.

Getting Started
#

If you want to experiment with CAO:

You need an AWS account with Bedrock access and permissions to use Claude models. Install Amazon Q Developer CLI or Claude Code. Install tmux (brew install tmux on macOS). Clone the repo: git clone https://github.com/awslabs/cli-agent-orchestrator. The README has configuration examples and workflows.

Realistically, plan to spend an afternoon getting this working. This isn’t a tool you spin up in 10 minutes.

Should You Use This?
#

Use CAO if you’re handling complex, multi-disciplinary tasks where single agents struggle. If you’re already on AWS and Bedrock, integration is straightforward. You need comfort with tmux and orchestration concepts.

Skip it if your tasks are straightforward. If you’re not on AWS or want to avoid lock-in, skip it. If you need something polished, this isn’t it.

For most developers, single-agent tools remain the right choice. For teams tackling large-scale modernizations or complex migrations, CAO offers a pattern worth exploring.

Check out the GitHub repository and the AWS blog post.

The future of AI tooling is coordination, not just capability. CAO is AWS’s bet on how that works. Whether it becomes standard or just one experiment, the pattern it represents is where things are headed.

Google Jules: Always on My Radar, But Never Quite the Star

Sun, 05 Oct 2025 00:00:00 +0000

Google Jules keeps showing up in my feeds, developer chats, and tool comparisons. It’s Google’s AI coding agent designed to handle the tedious parts of development: bug fixes, dependency updates, routine refactoring. Every time I see it mentioned, I think the same thing: “Interesting, but is it actually better than what I’m already using?”

After months of watching Jules evolve, I decided to dig deeper into their latest move: the Jules Tools CLI and API launch from October 2, 2025. You can read my initial take here: Jules Tools and API Launch. It’s a solid step toward making Jules feel more integrated into actual development workflows.

The CLI lets you trigger tasks directly from your terminal without switching to a browser. The API opens integration possibilities: Slack bots for bug reports, CI/CD pipeline hooks for automated reviews, custom dashboards for task monitoring. Google’s positioning this as “closer to how we actually build software,” and I understand the vision. They’ve also added session persistence and better environment variable handling.

The timing problem
#

Here’s where it gets interesting: Jules launched their CLI just days after GitHub shipped their own CLI updates for Copilot agent task management. I covered that too: GitHub CLI for Copilot Agent Task Management. GitHub’s version handles task creation, listing, real-time log monitoring, and status tracking, all from the command line.

It feels like GitHub beat Jules to the punch on making AI agents truly scriptable and automatable. This isn’t the first time Jules has felt like it’s playing catch-up rather than leading.

Jules’ technical approach
#

Jules follows a similar asynchronous execution model to OpenAI Codex and GitHub Copilot agents: cloning repositories to secure environments, analyzing codebases, planning changes, and delivering results via pull requests. Like its competitors, it can search documentation and execute changes in the background.

The system runs on Google’s Gemini 2.5 Pro model, optimized for reliability in background tasks rather than real-time interaction. It handles multiple concurrent tasks (up to 60 on higher tiers) and integrates deeply with Google Cloud Platform services. For teams already invested in the Google ecosystem, this creates natural workflow alignment.

The “fire and forget” model has appeal for maintenance work, dependency updates, and routine refactoring. You delegate a task, Jules handles the execution, and you review the results when ready.

Competitive positioning
#

When I compare Jules against the current landscape, it doesn’t consistently win. Here’s the reality:

OpenAI’s Codex delivers faster execution with GPT-5, excels at quick diagnostics and low-error code generation. The speed advantage matters for iterative development.

GitHub Copilot agents are already integrated into millions of developer workflows. Seamless GitHub integration and the network effects of being where developers already work.

Cursor feels like a complete IDE upgrade with background agents that handle complex refactoring. Multi-model support provides flexibility, and the diff UI makes accepting changes frictionless.

Windsurf offers sophisticated planning with Cascade agents, local indexing that keeps code private, and comprehensive MCP integration for tool ecosystems.

Jules excels at hands-off automation, but for real-time suggestions, deeper codebase understanding, or interactive development, the alternatives often provide better developer experience.

Developer adoption patterns
#

Based on recent discussions and usage patterns I’ve observed, most teams are adopting a multi-tool strategy where Jules is considered as one option among many:

Copilot remains the primary tool for daily coding and real-time assistance
Cursor handles complex refactoring and multi-file changes
Jules is considered as an alternative for overnight maintenance and dependency updates, though teams often stick with their existing tools such as GitHub Coding Agent

The free tier limitation (15 tasks daily) creates friction for initial adoption. Teams need to upgrade to see meaningful productivity gains, which slows broader adoption compared to tools with more generous free tiers.

Jules isn’t positioned as the “coolest” or most innovative tool. It’s positioned as reliable automation for routine work. That’s valuable, but it doesn’t generate the same excitement as interactive AI coding assistants.

The sequence shift philosophy
#

This connects to a broader philosophy I’ve written about: developer work doesn’t change, but the sequence does. The bottleneck isn’t typing speed or tool capabilities. It’s waiting for the right information to show up.

Jules embodies this sequence shift perfectly. Fire multiple tasks to background agents so when developers get to them, significant work is already done. The first hour becomes review and naming, not searching and guessing.

Strategic implications
#

Jules represents Google’s serious attempt to compete in the AI coding space. The CLI and API launch shows they understand that developer tools need to integrate into existing workflows, not create new ones.

The broader question is whether asynchronous agents like Jules will become the standard for team workflows, or if interactive assistants maintain their dominance. Both approaches have merit:

Asynchronous agents excel at handling routine maintenance, dependency updates, and tasks that don’t require immediate feedback. They’re perfect for “set it and forget it” scenarios.

Interactive assistants provide immediate value through real-time suggestions, context-aware completions, and collaborative problem-solving.

The CLI launch suggests Google believes the future includes both models. Teams will likely use interactive tools for active development and asynchronous agents for maintenance and automation.

The bottom line
#

Jules is a solid tool that fills a specific niche: reliable, hands-off automation for routine development tasks. It’s not revolutionary, but it’s useful. The CLI and API improvements make it more practical for team integration.

However, Jules consistently feels like it’s playing catch-up rather than leading innovation. The timing of their CLI launch relative to GitHub’s similar features reinforces this perception.

For teams already invested in Google Cloud Platform, Jules provides natural integration and workflow alignment. For everyone else, the competitive landscape offers alternatives that may better fit existing development patterns.

The AI coding space is evolving rapidly. Jules shows Google is committed to competing, but they’ll need to differentiate beyond “reliable automation” to capture significant market share.

If you’re curious about Jules, the free tier provides enough usage to evaluate the approach. The CLI makes it easier to integrate into existing workflows. But don’t expect it to replace your current AI coding tools. Instead, consider it as a complementary tool for specific use cases.

AI Agents for Real Productivity: What Works in 2025

CLI · PiniShv

CLI Agent Orchestrator: When One AI Agent Isn't Enough

The Problem #

How It Works #

Example: Mainframe Modernization #

The Reality Check #

Why It Matters #

Getting Started #

Should You Use This? #

Google Jules: Always on My Radar, But Never Quite the Star

The timing problem #

Jules’ technical approach #

Competitive positioning #

Developer adoption patterns #

The sequence shift philosophy #

Strategic implications #

The bottom line #

Related #