There Are Still No Best Practices

The harness, not the model: how I work right now

read in spanish

Introduction

I want to show how I work with AI day to day. This isn’t a guide for how you should work; it’s my experience after trying many of the tools that come out every week.

There is no recipe yet

One of my main theses is that, right now, there are no best practices. There isn’t a best toolset or a perfect workflow either. We still need to experiment and discover what works, for what, and for whom. Sharing what we do and what works for us can help us get closer to that goal.

There’s still no good alignment or consensus on how to get good results. There’s a lot of noise and smoke: tokenmaxxing, whatever goes viral that week, or anything someone publishes because it looks good. I also suffer from shiny object syndrome, and that makes me want to try everything.

I don’t think the frontier labs, the main players in this revolution, offer a clear guide yet.

The problem is not always the model

When an agent gives me bad results, I almost never blame the model. Often, the problem is that I don’t have a clear view of what I’m building, the architecture isn’t well designed, or something similar.

A setup I’m still changing

Every week I think the same thing: I like my Agentic Engineering setup, but I don’t love it. I like some parts and dislike others. I keep improving it by moving pieces around, with a simple principle: everything I do should be portable to any harness, with as few dependencies as possible.

For now, I know two things will stay in my setup this year: Pi and Cloudflare. I wouldn’t bet on anything else.

Right now I use Orca, which I find just as good as Herdr. I recommend both. I prefer the terminal, but an easy-to-use app helps when an emergency comes up. If I had something running remotely, I’d use Herdr 100% of the time.

Workspace

Working at the workspace level

One of the biggest changes I’ve made is to stop working at the individual project level and start working at the workspace level.

This workspace follows a monorepo philosophy: all my projects are in one place, under a single AGENTS.md, with global or project-level skills.

Personally, I think a monorepo is the best way to do agentic engineering right now.

Giving the workspace context

At the root, I have a projects.toml. It defines the projects, stack, aliases, progress, and other details. You can create whatever format works for you, with the fields you need: YAML, TOML, JSON, JSONL. The idea is to have one file that keeps the state and gives the agent enough context to understand and work with all the projects from one place.

AGENTS.md is one of the most important files in any harness. Its content matters, as does the way you approach it.

I’m not publishing mine. Figure some of it out yourselves: use what I’ve said to think about what your AGENTS.md or projects.toml could look like, then build it. You’ll learn from doing it.

Here are a few lines from an older version to give you a starting point:

# Agent Workspace

`~/fff-workspace` is the local workspace. Every project lives in a folder here and all work happens locally.

# Routing

1. Read `projects.toml` and match the request against project `aliases`...
2. If several projects match, ask one short question...

- Keep each main checkout clean on its `default_branch` ...

# Tools, memory and skills

- Workspace skills are canonical in `.agents/skills/<name>/SKILL.md`. Skills named are referenced by name, not path; when adding one, write it to `.agents/skills`

# Changes and PRs

- Never expose customer-derived information on public or potentially public surfaces, including code, comments, commits, PRs, issues, and docs. Use synthetic placeholders instead.

References

Here are three references that explain the idea well. I would read them in this order:

  1. Under the River, by Shopify.
  2. The Article Was Not About a Slack Bot, about the infrastructure under River.
  3. Building a Public AI Agent Workspace for Organizational Learning, about what happens when agent work stops being private.

Agents, Memory, and Executor

Agents and context

I use Pi with a Codex subscription. It’s a simple setup: my first prompt loads around 2.5k of context. I also use Grok Build thanks to my X Premium subscription.

I often use Orca to send audio transcripts about fixes or ideas and ask it to write them in Markdown or in Supermemory.

Memory

I’m using Supermemory, and so far I like it. I use the free plan and have my own Pi extension, so it doesn’t spend many tokens and I only query memory when I need it. It’s only connected to Grok Bot and Pi, nothing else.

Executor

With a single MCP, Executor lets me connect the others through Code Mode. I think it’s amazing and recommend it 100%. I think you’re making a mistake if you don’t use it or at least take a look.

Mine runs on Cloudflare. Pablo R. recently explained how he runs his, and I think it’s a very good path to follow:

Grok Bot

To me, it’s the first product that feels like a teammate—or really, like a team of workers, and good ones. I have a lot to say about it.

I don’t use it much right now because I don’t have the time, but I try to keep it simple. I have it connected to Executor with my MCPs.

The roles

I have a Chief who talks with me at the operational level, handles triage, and delegates to other bots. For now, it coordinates two agents, plus a few others I’m testing from templates I find on X. Its Marketplace has also just launched.

One agent helps me with content: ideas, references, advice, and organizing whatever comes to mind. The other is an engineer. They all share a computer, with Cursor installed so they can delegate the issues I write on GitHub to Cursor Cloud Agents.

What works and what I miss

The main difference I’ve noticed compared with agents like Hermes is that communication between agents feels effective and adds value.

What I don’t like—although it isn’t really a problem—is how opaque it is: you don’t know how much context you have, which models are being used, or how the agent loop works. You see nothing. But well, it had to have something bad.

The workflow

My workflow for features and fixes is simple and similar to what Matt Pocock advocates. I use his skills most of the time. I recommend creating others that complement them because they make development faster.

Otherwise, I use pstack. I’ve only been trying it for a short time, but it’s promising: good results, easy to understand, and a faster process.

I recommend this guide to get started.

Tools I use

For now, this first part ends here. In the next one, I’ll talk a little about the tools and how to use them in your own case. I think I’ll start with Pi, or with using Cloudflare infrastructure to build whatever you need.

If you want to ask me anything or send feedback, you have my socials.