My Agentic Engineering Setup: Terminal, Agents, and Workspace Management in 2026

Every few months, someone asks me to walk through my development setup. The answer has changed more in the past year than in the previous decade. My workflow is no longer centered on a code editor with a terminal on the side. It is centered on a terminal workspace with multiple AI agents running in parallel, and a code editor that I open only when I need to visually verify something the agents produced.

This post is a full walkthrough of my agentic engineering setup in March 2026: the terminal I use, the agents I run, how I manage my workspace, how I structure my CLAUDE.md files, and the supporting tools that tie it all together. This is not aspirational. This is what I actually use every day to ship production software.

The Terminal: Where Everything Happens

The terminal is the control center of an agentic engineering workflow. It is where your agents live, where you monitor their output, and where you coordinate their work. Choosing the right terminal setup is the most consequential infrastructure decision you will make.

I use Beam as my primary terminal workspace. The reasons are specific to how agentic engineering works:

• Split panes are essential, not optional. I typically run three to four visible panes at once. Two for active Claude Code sessions, one for Gemini CLI or a secondary agent, and one for running tests or tailing logs. Beam's split pane system lets me arrange these exactly how I need them and resize on the fly.
• Tabs organize by task, not by tool. Each tab in my setup represents a logical unit of work: "auth-refactor," "api-tests," "deploy-pipeline." Within each tab, I have the panes configured for that specific task. When I switch tabs, I switch contexts cleanly.
• Projects persist my layout. This is the feature that sold me. When I close Beam and reopen it tomorrow, my entire workspace is exactly as I left it: same tabs, same pane layout, same working directories. For long-running projects where I maintain specific agent configurations, this saves me fifteen minutes of setup every morning.
• Keyboard shortcuts for everything. In an agentic workflow, speed of navigation matters. I need to jump between panes, create new splits, close finished sessions, and switch projects without reaching for the mouse. Beam has over fifty keyboard shortcuts, and I use about twenty of them constantly.

The Agent Stack

I do not rely on a single AI agent. Different agents have different strengths, and a mature agentic workflow uses the right agent for each task. Here is my current stack:

Claude Code (Primary Agent)

Claude Code is my primary coding agent for anything that touches production code. I run it with Sonnet 4.6 for most tasks and switch to Opus 4.6 for complex debugging, architectural decisions, and security-sensitive code.

The reason Claude Code earns the primary position is reliability on multi-file changes. When I tell it to "add request validation to all API endpoints using our shared validation schema," it does it consistently across twelve files without missing one or introducing inconsistencies. That reliability is what matters in a production workflow.

I configure Claude Code through a combination of the global settings and per-project CLAUDE.md files. The global settings handle my preferences (model selection, permission allowances). The CLAUDE.md handles project-specific context.

Gemini CLI (Secondary Agent)

Gemini CLI fills a specific niche in my workflow: exploration and research. Its million-token context window means I can load an entire codebase and ask broad questions like "trace the data flow from the API request to the database write for user creation" or "find all places where we handle rate limiting." The answers are comprehensive because the model sees everything at once.

I also use Gemini CLI for prototyping. When I want to explore an approach before committing to it, the free tier lets me iterate without cost pressure. I might try three different implementations of a caching strategy in Gemini CLI, pick the best approach, and then have Claude Code implement the production version.

Aider (Specialized Agent)

Aider remains useful for specific git-focused workflows. Its tight integration with git means it creates clean commits, handles merge conflicts well, and works naturally with feature branch workflows. I use it less frequently than Claude Code, but for "make this change and commit it with a good message" type tasks, it is efficient.

Workspace Management: The Multiplier

Having good agents is necessary but not sufficient. The workspace management layer is what turns individual agent usage into a productive orchestration practice.

Here is my workspace management approach:

One project per major initiative. In Beam, I create a project for each significant piece of work. A project captures the full workspace state: tabs, panes, working directories, and terminal history. When I am working on the payments integration, I load the "payments" project. Everything is right where I left it.

Consistent pane naming conventions. I use the first line of each agent session as a visual identifier. When starting a Claude Code session, my first message is always a brief statement of the task: "Implement the webhook handler for Stripe payment events." This means when I glance across my panes, I can immediately see what each agent is working on.

Regular checkpoint reviews. Every thirty to forty-five minutes, I do a sweep across all running agents. I check each pane, review any completed work, merge what looks good, and redirect any agent that has gone off track. This cadence prevents drift without micromanaging.

CLAUDE.md: The Project Brain

My CLAUDE.md file is the most carefully maintained document in every project. It is the instruction set that every Claude Code session reads before starting work, and the quality of this document directly determines the quality of agent output.

Here is the structure I use for every project:

Section 1: Project Overview. Two to three sentences. What does this project do? What is the architecture? What is the deployment target? This gives the agent baseline orientation.

Section 2: Tech Stack and Versions. Explicit listing of every major technology with its version. This prevents the agent from using deprecated APIs or outdated patterns. I update this section whenever I upgrade a dependency.

Section 3: Code Conventions. Naming patterns, file organization, import ordering, error handling approach, logging conventions. The more specific you are here, the less time you spend correcting style issues in agent output.

Section 4: Testing Requirements. Which test framework, how to run tests, minimum expectations for test coverage on new code, and any testing patterns specific to the project (such as using factories for test data or specific mocking approaches).

Section 5: Boundaries. This is the most important section. What the agent must never do without explicit approval: modifying database migrations, adding new dependencies, changing public API contracts, modifying CI/CD configuration. Clear boundaries prevent the most costly mistakes.

Section 6: Common Commands. Build, test, lint, type-check, and deploy commands. The agent uses these to verify its own work. If your test command is npm run test:unit instead of npm test, the agent needs to know that.

"I spend about thirty minutes per week maintaining my CLAUDE.md across all projects. That investment saves me hours of correcting agent mistakes and re-explaining project conventions. It is the highest-ROI documentation I write."

MCP Server Configuration

My standard MCP setup includes four servers that I use across almost every project:

• PostgreSQL MCP server -- Connected to the development database with read-only access. The agent can inspect schemas, run queries, and understand data relationships without me pasting table definitions into chat.
• GitHub MCP server -- For PR management, issue tracking, and code search across the organization. The agent can create branches, open PRs, and check CI status autonomously.
• Filesystem MCP server -- Configured with scoped access to the project directory. This provides an additional layer of safety beyond what Claude Code's built-in file access offers.
• Memory MCP server -- Persistent knowledge graph that carries context between sessions. After a month of use, the memory server knows the project's architecture, past debugging sessions, and my preferences well enough that new sessions start with meaningful context.

I configure these through a project-level .mcp.json file that lives in the repository. This means every team member gets the same MCP setup when they clone the project and start their first agent session.

The Supporting Cast

Beyond the terminal and agents, a few other tools round out the setup:

VS Code -- I still open VS Code for visual tasks: reviewing diffs side by side, navigating complex type hierarchies, and using the debugger for stepping through code. But I spend maybe 20% of my time there, down from 80% a year ago.

Git with conventional commits -- Every agent-produced change goes through git. I enforce conventional commit messages and require all changes to go through feature branches. This creates a clean audit trail of what was human-authored versus agent-produced.

GitHub Actions for CI -- Every push triggers the full test suite, linting, type checking, and build verification. This is the automated guardrail layer that catches issues the agents might introduce. I trust my CI pipeline more than I trust any individual code review.

Linear for task management -- Connected via MCP server. I break features into Linear tickets, and agents can read ticket descriptions for requirements. When an agent completes a task, I update the ticket and move to the next one.

A Typical Day

Here is what a productive day looks like with this setup:

8:00 AM: Open Beam, load the current project. Review yesterday's in-progress work across the saved panes. Merge any completed work that passed overnight CI.

8:15 AM: Check Linear for today's priorities. Decompose the top priority into three or four agent-sized tasks. Write a brief description for each.

8:30 AM: Start Claude Code sessions in two panes with the first two tasks. Start a Gemini CLI session in a third pane to research an unfamiliar API I will need for the third task.

9:00 AM: First checkpoint. Review the output from both Claude Code sessions. One is done and looks good -- merge it, start the next task. The other needs a small correction -- provide feedback and let it iterate.

9:30 - 12:00 PM: Continue the cycle. Start tasks, monitor progress, review output, merge good work, redirect agents that drift. Three or four tasks completed per hour.

12:00 PM: Lunch. Agents keep working. Some will be done when I return.

1:00 PM: Review everything produced during lunch. Two tasks complete, one needs minor fixes. Merge the complete work, fix the issues, start afternoon tasks.

1:30 - 5:00 PM: Same cadence as the morning. By end of day, twelve to fifteen discrete tasks completed. That is the output of what would have taken a week of manual coding.

The key insight is that this productivity comes not from any single tool being magical. It comes from the system: the workspace that provides visibility, the agents that do the implementation, the CLAUDE.md that ensures consistency, the MCP servers that provide context, and the CI pipeline that catches mistakes. Each piece is necessary, and together they create something that is genuinely transformative.

Getting Started

If this setup sounds overwhelming, start simple. The minimum viable agentic engineering setup is:

1. Install Beam for workspace management with split panes and projects.
2. Install Claude Code and get an API key or subscription.
3. Write a CLAUDE.md for your current project with at least the project overview, tech stack, and boundaries sections.
4. Start with one agent session. Get comfortable reviewing agent output and providing feedback.
5. Add a second pane once single-agent work feels natural. Run two agents on independent tasks.

Scale from there. Add MCP servers when you identify specific pain points. Add Gemini CLI when you need a research agent. Add more panes as your supervision skills improve. The setup I described above took months to evolve. Yours will too, and that is fine. The important thing is to start.