A Group Chat Is Not an Engineering Workflow

Slack’s new Code channels are an interesting development. Humans and coding agents can collaborate in a shared conversation, inspect code, discuss changes, and coordinate implementation.

It’s a compelling idea. But it also highlights two different philosophies of AI engineering.

Should we bring everyone into the same conversation, or give specialized agents distinct responsibilities connected by explicit contracts?

Horizontal collaboration vs. structured responsibility

Slack Code resembles a horizontal organization. Humans and agents share a collaborative space, exchange information, and coordinate through conversation.

OpenOrc is closer to a structured organization with deliberate information and authority boundaries.

Our engineering workflow has four roles: Owner, Planner, Producer, and Reviewer.

The Owner and Planner explore architectural decisions. Those decisions become GitHub issues and repository contracts. The Producer implements against those requirements. The Reviewer independently evaluates the result. The Owner remains accountable.

We described this approach in Stop Sharing Context Between AI Agents. Start Sharing Contracts.

The important distinction is that each agent needs the right information, not everybody else’s entire conversation.

But this isn’t a traditional hierarchy either. As we argued in Stop Managing AI Agents Like Employees, agents aren’t synthetic employees with managers and reporting lines.

They’re specialized capabilities working within a human engineer’s system of responsibility.

Collaboration is not orchestration

The difference becomes more significant when engineering tasks run for hours, consume millions of tokens, and require multiple rounds of independent review.

Consider a simple question.

An agent reviews a pull request and approves it. Another agent then pushes a new commit.

Is the approval still valid?

In a conversation, somebody needs to notice that the reviewed code has changed.

In OpenOrc’s intended workflow, review acceptance is tied to the exact GitHub commit SHA. A new commit invalidates that acceptance, regardless of what the agents previously agreed.

The same principle applies to implementation authorization, merge decisions, and uncertain external operations.

These aren’t merely instructions asking agents to behave responsibly. They’re rules enforced by the orchestration system.

Agents make engineering judgments. OpenOrc controls the consequences of those judgments.

“But I can build that in Slack!”

Absolutely.

Slack can be the interface to a sophisticated engineering workflow. Connected agents and applications can implement structured reviews, persistent state, approval gates, and recovery logic.

But once you’ve built those mechanisms, you’ve also built an orchestration layer.

Slack provides the collaborative environment. The connected system provides the engineering guarantees.

There’s no reason the two couldn’t work together. Slack could eventually be another interface through which engineers interact with OpenOrc.

The question isn’t whether agents can coordinate through Slack.

It’s where the authoritative workflow lives.

The conversation isn’t the control plane

I don’t think shared conversations are bad. Our own Owner–Planner relationship depends on extensive, exploratory discussion.

But the output of that discussion needs to survive independently of the conversation.

Requirements should become contracts. Implementation should become committed code. Reviews should reference exact artifacts. Consequential decisions should remain attributable to the accountable human.

OpenOrc v1 begins at the executable GitHub issue, deliberately leaving upstream strategic planning outside its automated Task lifecycle. That separation reflects the different needs of exploratory planning and governed execution.

Slack Code makes AI engineering more collaborative.

OpenOrc aims to make autonomous engineering more governable.

Both are useful. They’re just not the same thing.

A shared conversation helps agents work together. A shared contract lets them work independently without losing coordination.