Setup is the part nobody wants to click through
A new workspace means creating agents, writing their instructions, connecting tools and setting schedules. Do it once and it is fine. Do it for ten projects, or for every client an agency takes on, and it is an afternoon of forms.
So we made Waggle drivable by the assistant you already have. There are two doors. hachi is an agent-first CLI: JSON on stdout every time, typed errors, stable exit codes, --dry-run, and a --yes gate on anything destructive. And there is an MCP endpoint, which exposes the same tools to any MCP client.
Both are live today. Install the CLI with brew install hachiflow/tap/hachi, then run hachi mcp serve for a local stdio server. Or skip the install and use the hosted endpoint at https://api.hachiflow.com/mcp. The tools are the same either way.
How we used it ourselves
We connected an AI coding assistant to the hosted endpoint and described about ten projects in a single file: a workspace for each, with its agents, connectors and schedules. We asked it to run hachi_plan, read the diff, and then run hachi_apply.
One call later there were ten workspaces with their agents, connectors and schedules in place. Nobody clicked through ten builders.
What was left was the per-workspace credentials, which is the part that should be left to a person. More on that below.
An agency, two clients, one file
Say an agency takes on two clients and wants an inbox agent and a reporting agent for each. First add the hosted endpoint to Claude Code, then sign in in the browser with your normal hachiflow login. It is OAuth through WorkOS AuthKit, so there is no API key to paste.
Then describe the work. The spec below is the whole shape: two workspaces, two agents each, and a weekday schedule on each inbox agent. Each agent is named for its client, so they are easy to tell apart in a list.
Run the plan first. It makes no change and prints what apply would do. Then apply. Apply is declarative and convergent: run it again and it reports nothing to do, edit an instruction and it becomes one update.
The whole example. Nothing secret is in the file: connector sign-ins and each workspace's model credential come back as handoffs for a person to finish.
The assistant gets the setup, a person gets the secrets
Apply does not pretend it can do everything. It returns a list of handoffs, the steps only a person can do: connector credentials, the model credential for each workspace, and invites. Run plan again after they are done and it should hold only no-ops.
Secrets never go in the spec file and never pass through the model. Credentials live in escrow, and agents get leases, never the values. They are also kept per workspace by design. An agency's clients each have their own keys and their own access, and one account-wide key would blur exactly that line.
So the assistant can do the typing, and the person does the part that needs trust: signing in to each client's tools once.
Why this suits an agency
An agency's setup is repetitive by nature. Each client gets a workspace, a few agents named for that client, the same handful of connectors and a morning schedule. That is a template with a name swapped in, which is something an agent is good at.
With the file in version control, adding a client is a few new lines and a plan to check them. The agency's assistant does the setup and the agency's people do the handoffs. Nothing about running the agents changes: they still run on a machine that belongs to the same person the agent belongs to.
Setup is free, running agents is not
An account can create workspaces and set up agents without a plan and without a machine. An agent created that way waits until there is somewhere to run it. Only running agents costs money, because running them takes compute.
We did this on purpose. An assistant should be able to build you the whole thing and show it to you before anyone is asked for a card. You pay when the work starts, not for the planning.
Next: agents that buy the service themselves
This part is planned, not built. We are building toward an agent that can pay for the service itself over HTTP 402, using Stripe's machine payments: the Machine Payments Protocol with Shared Payment Tokens. We have applied to be a Stripe Projects provider and for a Stripe Directory listing. Neither is approved yet, so none of this works today.
The second half is a human claim flow, also planned. An agent sets everything up, sends a claim link, and the person walks into a workspace that is exactly what they asked for. The only things left for them are the secrets.
Today an agent can do the setup, but a person still has to create the account and, to run agents, choose a plan. The goal is to close that gap without taking the person out of the decisions that matter.
Live today, and what is next
Live: the hachi CLI, local and hosted MCP, plan and apply from one file, handoffs for credentials, and free setup. Planned: agents paying over HTTP 402, and the claim flow. If you run an agency and want to try the live half, the endpoint and the example above are enough to start.