My Agentic Engineering Setup

Agentic Engineering sets out the principles. This companion article covers the tools and habits I use to apply them today. It will change as the harnesses and models improve.

Planning work across sessions

When work is too uncertain for one session, I sometimes use a Wayfinder map. It is a parent Backlog.md task with child investigations that resolve important decisions one at a time. I use it selectively. Once the route is clear, conventional implementation tickets are enough.

For larger efforts, Backlog tasks keep the record of scope, dependencies, decisions, and progress across sessions. They replace a single monolithic plan. Tickets coordinate the work, and each ticket's plan should be no more detailed than the work requires.

Operational guardrails

Before I start, I make important choices explicit and inspect the repository before asking questions it can answer. The harness keeps filesystem work inside the project or a private session workspace, so a coding task does not casually become a home-directory task. That keeps assumptions visible and the agent's operating context narrow.

I also prefer one focused task per session. When the context grows too large, Pi's /ctx-monitor shows what is consuming it and /handoff carries the decisions and state into a fresh session.

Isolated execution with worktrees

Independent Backlog tasks can run in separate Git worktrees. Dependent work stays sequential. Claude Code supports this through --worktree sessions and worktree-isolated subagents. In Pi, I use pi-worktree-agents for the same approach.

CoordinationBacklog.md

Ticket Aindependent scopeTicket Bindependent scope

→→

Isolated executionGit worktrees

Worktree Aagent/ticket-aAgent AWorktree Bagent/ticket-bAgent B

The goal is not to maximise the number of tickets. It is to keep the backlog current and the important reasoning close to the code, where Git makes completed work searchable without creating another system that can drift from the implementation.

One setup across harnesses

My coding harness is a public example of this split. The shared layer contains only user-authored resources both harnesses can use: AGENTS.md and skills. Pi keeps its own extensions, prompts, and agents. Claude Code keeps its own hooks, settings, themes, and agents. Credentials, sessions, caches, provider configuration, and generated state remain local.

A link script installs the shared resources into both Pi and Claude Code without maintaining copies. Its optional package step installs the Pi packages listed in the version-controlled manifest. These are currently pi-worktree-agents and pi-status-footer. Local Pi settings record what is installed on a given machine. I added and removed the artifacts in response to observed failure modes. Keeping the shared layer small means another harness can join later without moving its source of truth.