AI is making software execution faster.

Cross-team communication has not received the same upgrade.

An agent can inspect a repository, implement a feature, add tests, update documentation, and prepare a pull request before the humans have found a 30-minute opening for the architecture sync.

This creates a strange operating model:

AI execution speed
        ↓
Minutes or hours

Cross-team coordination speed
        ↓
Calendars, meetings, follow-ups, archaeology

The technical system accelerates. The communication system remains scheduled.

I think that mismatch will become one of the defining constraints of the AI-native software development lifecycle.

My opinion is simple:

Cross-team communication should be asynchronous by default, structured as a protocol, and escalated to synchronous conversation only when ambiguity, conflict, or risk requires it.

Async is not the goal by itself. Efficiency is the goal.

Bad async communication is just a slow meeting with worse facial expressions. The useful shift is from messages to operational artifacts: durable, addressable, typed, owned, and actionable communication that both humans and AI can process.

AI Moves the Bottleneck

Traditional software delivery assumed implementation was expensive.

Engineers needed time to investigate, code, test, document, and deploy. Communication happened around that work. A weekly sync was often fast enough because the implementation itself took days or weeks.

That assumption is weakening.

In The Software Engineer’s Multi-Agent Flow, I described a workflow where specialized agents can plan, implement, test, review, and document in parallel. In Looking Ahead: Stronger Models, Better Harnesses, Different Work, I argued that stronger models inside better harnesses may take responsibility for increasingly complete slices of delivery.

As execution compresses, waiting becomes more visible:

  • waiting for another team to discover a change,
  • waiting for someone to identify the correct reviewer,
  • waiting for a meeting to clarify a dependency,
  • waiting for an owner to acknowledge a migration,
  • waiting for six people to reconstruct why a decision was made.

The bottleneck moves from doing the work to establishing shared understanding.

This is why Hierarchical Context matters. It gives organizational knowledge an address and defines where authority lives.

But stored context is only half of the problem.

Organizations also need a protocol for how context changes move between teams.

Async Does Not Mean “Send a Message and Disappear”

Asynchronous communication is often reduced to “not a meeting.”

That definition is too weak.

GitLab, one of the most visible practitioners of distributed work, describes async communication as work that can move forward without participants being present at the same time. Its async communication guide also makes the hard part explicit: async requires intentionality, sufficient context, clear next steps, durable documentation, and information people can find later.

In engineering terms, async communication needs more than transport.

Weak async Effective async
“FYI, API changing soon” Versioned change proposal with affected interfaces
Message sent to a broad channel Artifact routed to declared owners
No expected response Required acknowledgement with a deadline
Context embedded in conversation Evidence and decisions linked by stable address
Silence interpreted optimistically State tracked explicitly
Meeting scheduled when confusion appears Escalation triggered by defined conditions

The difference is protocol.

Email is transport. Slack is transport. GitHub is transport. A meeting is transport with synchronized clocks and usually more coffee.

A protocol defines what the message means and what happens next.

Pull Requests Already Show the Pattern

Software teams already use a successful asynchronous protocol every day: the pull request.

A pull request has:

  • a stable address,
  • a proposed change,
  • a diff,
  • authorship,
  • requested reviewers,
  • discussion,
  • explicit review states,
  • automated checks,
  • and a merge decision.

GitHub documents three review outcomes: comment, approve, and request changes. It also supports required reviews before merge (GitHub pull request review documentation). Its CODEOWNERS mechanism can automatically request the appropriate reviewers when owned files change.

That is not merely collaboration tooling. It is a communication protocol embedded in the delivery system.

We should extend the same thinking beyond code:

  • architecture changes,
  • platform migrations,
  • API deprecations,
  • operational learnings,
  • security standards,
  • shared model changes,
  • and cross-team decisions.

Today, many of these still travel as prose broadcasts. The message contains information, but the system does not know what the recipient must do with it.

Communication Needs Types

“Announcement” is not a useful message type.

It says something was said. It does not say what happened.

A cross-team engineering protocol should define a small number of artifact types:

Type Meaning Typical required response
proposal A decision is open for review Comment, approve, or object
decision A choice has become authoritative Acknowledge applicability
breaking-change A consumer contract will become incompatible Assess impact and plan
migration Consumers must move from one state to another Commit to milestone
deprecation A capability is entering end of life Identify remaining usage
incident-learning An event produced reusable operational knowledge Apply or explicitly reject action
standard-update A governing rule changed Confirm compliance or exception
request-for-capability One team needs another team to provide something Accept, negotiate, or decline

Types let automation behave predictably.

An AI agent can treat a proposal differently from a breaking-change. A human should too.

Without types, every message begins with the same manual classification task: “Is this informational, or is somebody quietly assigning me six weeks of work?”

The Cross-Team Context Contract

The unit of communication should be a context contract.

This is not a legal contract. It is a structured agreement about what changed, who is affected, what action is expected, and how completion will be verified.

A minimal artifact might look like this:

apiVersion: context.fiodar.ai/v1alpha1
kind: CrossTeamChange

metadata:
  id: platform.identity.token-v2
  type: breaking-change
  source: platform/identity
  owner: team-identity
  publishedAt: 2026-07-08T14:30:00-07:00

scope:
  capabilities:
    - authentication
  affectedServices:
    - checkout-api
    - billing-worker
  sensitivity: internal

change:
  summary: Token v1 will no longer be accepted after the migration window.
  decision: Consumers must adopt token v2.
  evidence:
    - adr://platform/identity/0042
    - incident://security/2026-017
  supersedes:
    - platform.identity.token-v1

response:
  required: migration-plan
  owners:
    - team-checkout
    - team-billing
  acknowledgeBy: 2026-07-15
  completeBy: 2026-09-30

verification:
  checks:
    - no token-v1 traffic for 14 days
    - consumer contract tests pass

escalation:
  conditions:
    - owner-disputes-scope
    - deadline-at-risk
    - security-exception-requested

The format is less important than the semantics.

The artifact answers:

  1. What happened?
  2. Who owns the message?
  3. Who is affected?
  4. What evidence supports it?
  5. What response is required?
  6. By when?
  7. How will completion be verified?
  8. What conditions require synchronous escalation?

This is the cross-team equivalent of an AI-executable ticket. The communication is complete enough that a human or agent can begin useful work without first scheduling interpretation.

Use Precise Requirement Language

Cross-team communication often fails because ordinary language hides obligation.

Consider:

Teams should migrate when possible.

Does should mean required? Recommended? Eventually? Before the current maintainer retires?

Internet standards solved this with explicit requirement levels. RFC 2119 defines terms such as MUST, SHOULD, and MAY so specification authors can distinguish absolute requirements from recommendations and genuine options.

Cross-team artifacts do not need to imitate an RFC in every detail, but they need the same precision:

  • MUST: required for compatibility, security, or policy.
  • SHOULD: expected unless a documented reason justifies deviation.
  • MAY: optional behavior.

This prevents polite language from becoming accidental ambiguity.

It also helps AI agents. “Consider updating the client” is a weak execution constraint. “Consumers MUST update before version 1 is disabled” is machine-actionable.

The Protocol State Machine

Messages need state.

Otherwise, the sender sees “posted,” the recipient sees “saved for later,” and the organization sees “apparently handled.”

A useful lifecycle is:

Draft
  ↓
Published
  ↓
Routed
  ↓
Acknowledged
  ↓
Planned
  ↓
Applied
  ↓
Verified
  ↓
Archived

Each transition has a specific meaning:

State Meaning
Draft Artifact is being prepared and has no operational force
Published Producer asserts the artifact is ready
Routed System identified and notified affected owners
Acknowledged Consumer confirms receipt and ownership, not agreement
Planned Consumer records intended response and timing
Applied Required change is implemented
Verified Defined evidence confirms the desired outcome
Archived Artifact remains discoverable but requires no further action

Acknowledgement is deliberately separate from approval.

“I received the migration notice” is not the same as “I agree with the architecture” or “the migration is complete.” Many organizations collapse these states into a thumbs-up emoji, which is a charmingly optimistic transaction protocol.

AI Becomes the Router, Not the Authority

AI can make this protocol substantially more efficient.

When a new artifact is published, agents can:

  • identify affected services from dependency and ownership graphs,
  • propose reviewers,
  • compare the change with existing decisions,
  • find unresolved exceptions,
  • summarize impact for each consumer,
  • generate draft migration tasks,
  • detect missing fields,
  • monitor acknowledgements and deadlines,
  • and assemble evidence for verification.

The AI should not silently decide that a team accepted a breaking change.

Authority remains explicit:

AI may AI must not
Recommend affected consumers Invent ownership
Draft summaries and tasks Approve on behalf of owners
Detect contradictions Resolve policy conflicts without authority
Track protocol state Treat silence as consent
Suggest escalation Perform high-impact escalation autonomously
Collect verification evidence Redefine success criteria after publication

This follows a broader principle: models interpret and propose; deterministic systems and accountable humans authorize.

Async by Default, Sync by Exception

Not every engineering problem belongs in a document thread.

Synchronous communication is appropriate when:

  • teams disagree about authority or scope,
  • risk is high and time is short,
  • ambiguity is producing repeated async loops,
  • sensitive interpersonal conflict is involved,
  • a live incident requires rapid coordination,
  • or the cost of waiting exceeds the cost of interruption.

The protocol should make escalation explicit.

Can the recipient act from the artifact?
  ├─ Yes → Continue asynchronously
  └─ No
      ├─ Is required information missing? → Update the artifact
      ├─ Is ownership unclear? → Route to governance
      ├─ Is there material disagreement? → Focused sync discussion
      └─ Is there immediate risk? → Incident channel

The meeting is not a failure. An unstructured meeting that produces no durable decision is.

After any synchronous discussion, the resulting decision, evidence, and required actions should return to the protocol. GitLab’s communication guidance similarly emphasizes writing down conclusions from offline conversations to preserve a source of truth (GitLab communication handbook).

Sync resolves ambiguity. Async preserves the resolution.

Borrow from Event-Driven Systems

Software systems do not require every service owner to attend a meeting when an event occurs.

They define events, metadata, consumers, and delivery behavior.

CloudEvents standardizes core event context such as identifier, source, type, and specification version so events can move across systems in a consistent form. AsyncAPI provides machine-readable descriptions for message-driven APIs.

Human communication is more nuanced than event processing, but the design principles transfer:

  • identify the source,
  • define the message type,
  • give every occurrence a unique address,
  • separate routing metadata from payload,
  • specify the schema,
  • make consumers discoverable,
  • handle duplicates,
  • and design for failure.

This does not mean turning people into Kafka consumers.

It means refusing to run enterprise coordination on undocumented message semantics.

Routing Must Follow Ownership

Broadcasting is the easiest communication strategy for the sender and the most expensive for everyone else.

The sender posts once. Hundreds of recipients classify relevance manually. Most ignore it. A few assume someone else will act. One person creates a spreadsheet.

Effective routing uses organizational metadata:

  • service ownership,
  • API consumption,
  • deployed dependencies,
  • data contracts,
  • team responsibilities,
  • regulatory scope,
  • and current migration state.

This is where the protocol complements Hierarchical Context:

Hierarchical Context Cross-team protocol
Defines where knowledge lives Defines how changes move
Establishes authority and inheritance Establishes producers and consumers
Resolves applicable context Routes actionable context
Preserves organizational memory Drives organizational response
Answers “what governs this?” Answers “what must happen next?”

The hierarchy supplies the address space. The protocol supplies the traffic.

Response Windows, Not Instant Replies

Async communication fails when “async” secretly means “respond immediately, but in writing.”

Every message type should have an expected response window:

Priority Example Expected response
Routine Proposed standard update 5 business days
Scheduled Migration or deprecation 2 business days to acknowledge
Urgent Imminent compatibility risk Same business day
Critical Active security or production incident Synchronous escalation

The exact windows depend on the organization.

What matters is that they are explicit. This protects focus while preventing important communication from disappearing into an infinite backlog.

Measure Flow, Not Message Volume

The protocol is not successful because it produces many artifacts.

Measure whether cross-team work moves more reliably:

  • time from publication to correct routing,
  • time to acknowledgement,
  • percentage of affected consumers identified automatically,
  • number of unplanned escalations,
  • migration completion rate,
  • stale or superseded artifact rate,
  • repeated questions after publication,
  • meetings required per cross-team change,
  • and changes completed without synchronous coordination.

The goal is not zero meetings.

The goal is fewer meetings required to reconstruct information that should already be operational.

Start with One Change Type

Do not begin with a universal communication ontology.

Choose one recurring cross-team problem. API deprecation is a good candidate.

  1. Define the artifact schema.
  2. Name the producer and consumer roles.
  3. Establish acknowledgement and completion states.
  4. Set response windows.
  5. Connect service ownership data.
  6. Let AI suggest affected consumers and draft impact summaries.
  7. Require humans to confirm ownership and decisions.
  8. Track the change through verification.
  9. Compare meeting load and missed dependencies with the previous process.

Once the protocol works for one high-value flow, extend it to migrations, standards, and incident learnings.

The discipline should earn its complexity.

Communication Becomes Part of the SDLC

The AI-native SDLC cannot remain:

Plan → Build → Test → Deploy

It increasingly looks like:

Intent
  → Resolve inherited context
  → Publish typed change
  → Route to affected owners
  → Acknowledge and plan
  → Build with humans and agents
  → Verify locally and across consumers
  → Update organizational memory

Communication is not outside the delivery system.

It is one of its control planes.

This extends the argument in Agile SDLC with Vibe Engineering: when AI becomes a first-class execution layer, intent and validation become more important. Cross-team communication needs the same upgrade. It must carry enough structure for distributed humans and agents to act without continuous synchronization.

The Real Promise of Async

Async is often sold as a remote-work benefit.

In an AI-native enterprise, it becomes an architectural requirement.

Agents do not need everyone online at the same time. Distributed teams should not either. But both need communication that is complete, trustworthy, and connected to action.

The future is not an organization where nobody talks.

It is an organization where:

  • routine coordination does not require synchronized calendars,
  • decisions remain available after the meeting ends,
  • owners receive relevant changes instead of broad announcements,
  • agents perform the mechanical work of routing and impact analysis,
  • humans retain authority over commitments and exceptions,
  • and synchronous time is reserved for ambiguity, conflict, creativity, and risk.

Implementation is becoming asynchronous, parallel, and agent-assisted.

Cross-team communication must evolve with it.

Otherwise, we will build software at machine speed and coordinate it through calendar invitations.