Build Your Own Profile

The point was never my profiles

We have pointed this harness at autonomous deploys, a security review, an architecture call, and a pricing decision. Every one of them ran on a profile the harness already ships. That was the demo. The point was always something else.

The point, stated back in Issue 1: agent orchestration is an engineering discipline, and you do not learn a discipline by watching. So this issue we stop watching. From an empty file to a profile you can run, on a domain nobody in the registry has covered: developer relations. Then we push it to the repo, because a profile you cannot contribute is just my opinion with better formatting.

I authored one for this issue, devrel-council. It is not in the registry yet, and pushing it there is what this issue is about. By the end you will have watched it argue a live decision. Here is how it got built.

A profile is four decisions

Issue 4 made the claim: a profile is not a config file, it is an assembly. Four decisions turn an empty YAML file into one.

1. Which agents sit at the table.
2. Which pattern they run.
3. What counts as proof.
4. What goes in and what comes out.

Get those four right and the machinery (the Arbiter, the rounds, the documented dissent) comes for free. Get them wrong and you have a list of names in a file that produces mush. Let me make each decision out loud.

Decision one: which agents

A DevRel call has a specific shape of conflict. You want adoption. You do not want to strand the developers who already shipped on you. You want the market to see you as a platform worth building on. And you want the change to be good for the person writing the integration. Four pulls. Four agents, all from the registry. Here is the assembly, trimmed to the seats:

Catalyst makes the case for adoption and shipping. Advocate speaks for the developer on the other end of the change. Navigator reads the ecosystem. Sentinel guards the people who trusted the old behavior, and it gets speaks-last, so it stress-tests whatever consensus the room builds before that consensus can leave the room. Steward is optional and active by default, there for the moment a developer decision turns into a contract question. It earned that seat today, as you will see.

No arbiter of my own. The Arbiter is the one piece I do not choose. It frames the question and runs the room, and it documents the dissent when the room splits, the same in my profile as in every shipped one.

Decision two: which pattern

Broadcast deliberation, because a DevRel call is a decision, not an artifact chain. Nobody is handing a document down a line. Everybody argues in the open, then the Arbiter synthesizes.

The two tension_pairs are the part I want you to steal. You do not hope the conflict shows up. You name it. [catalyst, sentinel] is ship-it against don't-break-them. [advocate, navigator] is the developer's reality against the market's story. I set those pairs on purpose because they are the exact two fights a deprecation starts.

Decision three: what counts as proof

This is the subtle one, and Issue 4 already did the heavy lifting. Evidence standards do not live in the profile. They live on the agents. Catalyst is convinced by adoption signal. Sentinel is convinced by the count of developers a breaking change strands. Those bars belong to the agents. My job is to decide which of them gets a seat, and that choice is the evidence standard for the domain. Putting Catalyst and Sentinel in the same required list is me saying a DevRel decision must satisfy both adoption and trust, or it does not pass.

Decision four: what goes in, what comes out

The input contract is the shape of a DevRel decision. Note ## Who Built On This. A strategic-council brief asks for Stakes. A DevRel brief asks who gets hurt if this changes, because that is the question the whole domain turns on. The output adds a developer_impact section and a migration_and_comms section that a generic strategy memo would never carry. Same Arbiter, different contract at both ends.

Validate, then run

A profile that does not parse is a text file with ambitions. So:

One line, pulled from the full run that checks every agent, profile, and domain in core. The profile parses. Then I pointed it at a decision that lands in a DevRel lead's inbox: deprecate a v1 REST API. Three years GA, 800 live integrations, 40% of traffic still on it, twelve big partners with contracts that name v1 endpoints, and a v2 that changes auth and pagination so migration is real work, not find-and-replace. The full brief fills the four sections above.

Session 2026-07-01-devrel-council-mr2dk23w. Six rounds. It ran.

What the council said

Let me be straight about one thing before the good part. The formatted memo did not render to disk. The Arbiter's final synthesis turn, the one that assembles the memo, ran past the profile's timeout and the run exited.

That is the same class of synthesis-turn timeout the series hit on the security review a few issues back. My profile's own save_transcript_and_exit is why I still have every word the agents said. So I am not going to show you a clean memo file. I am going to show you the live debate, which is the proof the profile works.

It opened exactly along the tension pairs I set. Catalyst went straight at the cost of doing nothing.

The dual-maintenance tax is a compounding cost, and it's charged against the one team that ships all your new revenue. [...] v2 shipped eight months ago and 40% still haven't moved. That's the proof: "build v2 and they'll come" already failed.
Catalyst

Sentinel, in the speaks-last seat, refused to let that become a stampede.

This is a one-shot, irreversible public commitment, and we are proposing to aim it at ~800 relationships who never signed up for this migration (we did). Three years of "v1 is reliable, build on it" were slow deposits; this is a fast, large withdrawal.
Sentinel

Navigator read it as a market signal.

A deprecation done badly hands your competitors their best sales line: "build on us, we don't pull the rug."
Navigator

And then the optional seat earned its keep. Steward found the landmine nobody else was looking at.

Those multi-year contracts that explicitly name v1 endpoints are binding legal obligations, not integrations. [...] The announced sunset date is a legal artifact before it is a product decision.
Steward

That catch changed the answer. Catalyst had opened with "announce inside 30 days." By the close it had conceded the exact point Steward raised.

"Announce within 30 days" as I first said it was sloppy: taken literally it bundles the partner dates into the public commitment, and on a one-shot irreversible announcement that sloppiness is how you publish yourself into a breach. Conceded.
Catalyst

The council landed on deprecate. The security liability and the dual-maintenance tax are genuine, and nobody in the room defended keeping both APIs forever. What the room rejected was the flat six-month calendar. Announce the direction and freeze new v1 signups on day one. Carve the twelve contract partners onto private, contract-aligned schedules, and never let them become public exceptions. Put the insecure auth on its own faster clock. Give the general population nine months instead of six, because what gates them is human scheduling latency, how fast partners and legal can move. And gate the whole sunset on migration showing up in the traffic numbers, not on how many announcement emails went out.

Nine months is not my number, but the Arbiter's reasoning for it uses my own concession [...]: segment before announcing, keep every carve-out private, decouple the security clock, fail loudly not silently, and optimize migrated-vs-broken rather than when-the-cost-stops.
Sentinel

Deprecate, yes. On a deadline that breaks 800 integrations, no. That is an answer, argued out of a profile that did not exist yesterday.

Push it back

Here is the whole reason this issue is the finale. Everything I just did is a file.

The profile is a file. The registry is a file. Adding yours is a pull request. You author a profile.yaml for the decisions your field makes, you run it, you drop it in the profiles directory, and you open a PR. There is no plugin system to learn and no framework fork to maintain. The docs walk the whole path.

So author one. A clinical-review council. A go/no-go launch council for your own product. Whatever decision your field argues on repeat. The domains I have not covered outnumber the ones I have, and every one of them is a profile.yaml and a PR away from sitting in the registry next to mine.

Twelve issues, closed

Issue 1 made an argument: agent orchestration is an engineering discipline, not a prompt-tuning hobby. Twelve issues later, I have tried to make that argument stand on artifacts instead of a slide. The one that mattered most was the profile itself, the primitive most frameworks drop. And the run that proved the point was watching the same machinery argue a security review and a pricing call, holding its dissent in ink both times.

And now this. The harness was never the profiles I shipped. It was that you can write your own, and now you can. The proof is a profile.yaml with your domain's name on it and a PR number.

So build one. The repo is here, the docs are here, and the first community profiles are the only next issue I actually want to read.