System trace

Positioning item → published post

One PI action card flows through six sequential skill invocations. Each produces a versioned artefact. The human makes one decision: publish or hold.

PI action → evidence → draft → archive 4 model skills · 1 human decision

Scenario

Input: PI-23 — "Write a post on agent-readable processes as an EM KPI."
Output: a published LinkedIn post, archived with metadata in outputs/linkedin/.
Synthetic but structurally accurate. Real skill contracts, real file paths, real decision rules.

PI Action — entry point

A typed positioning item is the starting artefact.

action-planner already produced this card from a hypothesis. It defines the angle, audience, and success metric — not the text.

# market-state/actions/PI-23.md

---
id: PI-23
kind: content
type: linkedin-post
hypothesis: agent-readiness-framing
created: 2026-03-18
---

Angle: agent-readable processes as an engineering manager KPI —
not a dev tool story, a delivery accountability story.

Target audience: CTO and VP Eng considering AI adoption.
Maturity level: has heard of agents, hasn't shipped any yet.

Why now: C-level using this language publicly; framing window is open.
Metric: saves + comments from technical leads.

Skill invoked: none — this card is the input. Writing starts only after evidence is collected.

↓

Evidence — before writing

evidence-finder pulls proof points from the repo.

Searches cases/, products/, market-state/. Writing starts only when a verifiable evidence brief exists.

# outputs/evidence/pi-23-evidence.md

## From cases
- Askona: 40+ services, 20+ distributed teams — delivery predictability was existential.
  AI embedded into SDLC: code review, architecture review, test generation. Not a pilot.
- PersonaClick: ML on 199M+ user profiles — production, not experiment.

## From products
- "AI in the daily work of teams — reproducible practice the team runs
   without you tomorrow." (products/ai-driven-head-of-engineering.md)
- "I talk to engineers as a peer, not as a deck-and-framework person."

## From market-state signals
- 3 recent signals type `tool-search` from CTO-level contacts
- 2 signals: `leadership-change` at companies with "AI transformation" in postings

## Numbers available
- 200+ engineers managed or influenced
- $680M+ revenue architecture
- 4–8 week AI Enablement programme: real tasks from backlog, artefacts on the way out

## Evidence verdict
Strong case available. Use Askona delivery angle + "reproducible practice" framing.
Avoid: generic "AI is transforming" language. Ground every claim in a case.

Constraint: evidence-finder does not write the post. It surfaces what's verifiable. No invented metrics. Every number traces back to a case file.

Skill invoked: evidence-finder

↓

Draft — algorithm-aware, maturity-aware

linkedin-post-writer produces the first draft.

Reads PI action + evidence brief. Applies LinkedIn algorithm awareness (hook structure, no links in body) and maturity-aware framing for the target audience.

# Draft (pre-humanizer) — not yet publishable

Most engineering managers measure their AI adoption by tool adoption.
That's the wrong metric.

The right question: can your agents act on your processes without
a human translator in the loop?

I call this "agent-readable" delivery. It means:
— your sprint ceremonies have a predictable schema
— your PR process has explicit acceptance criteria
— your incident response follows a documented decision tree

When those exist, an agent can participate. When they don't,
you get a very expensive autocomplete.

I've seen this at 80-engineer fintechs and 200-engineer enterprises.
The bottleneck is never the model. It's the undocumented tribal knowledge
that makes your delivery process illegible to everything — including new humans.

The KPI isn't "which tools do your engineers use."
It's "what percentage of your delivery process can an agent traverse
without asking a human to explain the unwritten rules."

Skill invoked: linkedin-post-writer — draft is correct but not yet publishable. Two more passes remain.

↓

Humanizer — surface patterns removed

humanizer strips AI-generated patterns.

Rhythmic flatness, parallel list symmetry, transition phrases, abstract summary conclusions. These are the surface tells that make text read as model-generated.

What gets changed

· "Most X measure by Y. That's the wrong metric." → direct open, no thesis preamble
· Parallel triple list (3 bullet items, same grammatical structure) → flattened
· "I call this…" constructions — reduced to one
· Summary restatement at the end — cut

What stays

· The core argument and its structure
· The specific framing ("agent-readable")
· The metric formulation at the end
· All evidence-grounded claims

Skill invoked: humanizer — output passed directly to expert-voice. No separate file written.

↓

Expert voice — depth calibrated

expert-voice checks that it reads as practitioner, not consultant.

Different failure mode from humanizer. Listens for curse-of-knowledge gaps, hedging that undercuts the claim, and missing concrete grounding.

What expert-voice fixes

· "agent-readable" used without grounding it in reader's reality → one concrete anchor added
· Post ends with a metric question but no lived-experience signal → Askona anchor inserted
· One hedging phrase ("might mean") → removed

Why a separate skill?

· humanizer removes surface patterns
· expert-voice removes depth failures
· Same skill can't reliably catch both
· Running both in sequence covers both surfaces

Skill invoked: expert-voice — output is the final text, ready to publish.

↓

Archive — automatic, silent

chronographer archives after publication. No manual step.

Every published post becomes a data point. The archive feeds back into the system — market-analyst can read post history when synthesizing what's resonating.

# outputs/linkedin/2026-03-19-agent-readable-processes.md

---
date: 2026-03-19
platform: linkedin
pi_action: PI-23
hypothesis: agent-readiness-framing
status: published
---

[final post text]

Skill invoked: chronographer — runs automatically. No human trigger required.

What this trace produced

Evidence brief

pi-23-evidence.md

grounded, verifiable, traceable

Draft

algorithm-aware

hook, no links, maturity framing

Processed text

humanized + expert

no AI patterns, practitioner voice

Architecture decisions

Why evidence before writing?

Writing without evidence produces claims the system can't verify. evidence-finder runs first — always. This is what keeps content grounded in real cases and real numbers, not invented metrics.

Why two separate passes?

humanizer removes AI surface patterns. expert-voice removes depth failures. They fix different problems — the same skill can't catch both reliably.

Why archive automatically?

Post history is a system input, not just a record. A post with high engagement from CTOs is a signal. chronographer creates the data. market-analyst reads it. The loop closes.