From Domain Expert to Agent Architect

The knowledge transfer bottleneck

Every AI project hits the same wall. Not the model. Not the infrastructure. The gap between the people who know how things should be done and the people who build the systems. The SOC analyst knows what lateral movement looks like. The sales manager knows when a deal is at risk. The compliance officer knows which transactions need a second look. None of them can write a prompt. None of them should have to.

So the company hires an engineer. The engineer interviews the domain expert, writes a prompt, and shows it to them. The domain expert squints at it and says, "That's not how we do it." The engineer rewrites. The domain expert reviews again. "Closer, but you're missing the part where we check the auth logs before escalating." Another rewrite. Another review.

This loop — interview, translate, review, revise — is the actual bottleneck in AI adoption. Not model quality. Not token costs. Not infrastructure complexity. Knowledge transfer. The domain expert has the methodology in their head. The engineer has the technical skills to encode it. Neither can do the other's job. So they iterate, slowly, losing fidelity at every handoff.

Why prompts require engineers

A prompt looks like English, but it isn't. It's code wearing a natural language costume. Writing a production prompt means understanding token limits, managing context windows, defending against injection attacks, formatting output for downstream parsing, and wiring up tool calls with the right schemas and error handling.

When the SOC analyst says "check for lateral movement patterns," the engineer has to translate that into tool call sequences — query the SIEM, filter by time window, cross-reference with asset inventory, check for impossible travel, format as structured JSON. The analyst's five-word instruction becomes fifty lines of prompt engineering. The domain expert can't write a prompt any more than they can write a Python script. The language shifted, but the engineering demands remained.

Why skills require domain experts

A skill is a markdown file. Not a prompt template. Not a code module. A markdown file with four sections: when to activate, how to think about the problem, what the output should look like, and what to avoid. That's it.

The platform handles everything else — token management, tool calling, context isolation, error recovery, output formatting. The skill author doesn't think about any of that. They think about methodology. How should an expert approach this class of problem?

Here's what it looks like when a SOC analyst writes a threat triage skill:

# Skill: Threat Triage

## Trigger
Activate when: alert, threat, suspicious activity, incident

## Methodology
1. Pull the alert details from the detection system
2. Check user's auth history in the identity provider
3. Search logs for correlated events in the past 24 hours
4. Assess severity: critical if credential compromise + data access
5. Recommend containment actions, don't execute them

## Output
- Severity assessment with reasoning
- Timeline of correlated events
- Affected entities (users, hosts, systems)
- Recommended actions (ranked by urgency)

## What NOT to do
- Never auto-isolate hosts without confirmation
- Never disable user accounts without confirmation
- If insufficient data, say so — don't guess

The analyst didn't need to know how the platform queries the SIEM or understand context windows or tool schemas. They wrote down what they do every day — the methodology they've refined over years of incident response — and the platform turned it into agent behavior. No handoff, no fidelity loss, no three-week iteration cycle.

Same format, different world: a sales manager's deal review

The skill format isn't domain-specific. It's a universal structure for encoding expert methodology. To prove it, here's a completely different domain — a sales manager writing a deal review skill:

# Skill: Deal Review

## Trigger
Activate when: deal review, pipeline check, forecast accuracy, deal health

## Methodology
1. Pull the deal record from CRM — stage, amount, close date, activity history
2. Check engagement recency: last meeting, last email, last champion contact
3. Flag stale deals: no activity in 14+ days while in Stage 3 or later
4. Validate close date: if pushed more than twice, mark as at-risk
5. Check multi-threading: single-threaded deals over $50K are always at-risk
6. Compare to historical win patterns for this segment and deal size

## Output
- Deal health score (green / yellow / red) with reasoning
- Key risks (ranked by impact on close probability)
- Recommended next actions for the rep
- Comparison to similar deals that closed (or didn't)

## What NOT to do
- Never change the deal stage or close date automatically
- Never send communications to the prospect
- Don't flag deals under 7 days old — too early to assess

Different domain. Different systems. Same format. The thresholds are specific — 14 days for stale, $50K for multi-threading, twice-pushed close dates. This is institutional knowledge that lives in one person's head until they write it down. No engineer could invent these numbers. They come from experience.

The new job title: Agent Architect

"Agent Architect" isn't an engineering role. It's a domain expert who understands how to decompose their expertise into skills, connections, and automations. They don't write code. They write methodology. They define what the agent should know, what it should access, and how it should reason. The platform does the rest.

The Agent Architect's workflow looks nothing like software development. They map their team's decision-making processes: which decisions are routine, which follow a repeatable methodology? Those methodologies become skills. The systems they query become connections. The recurring tasks become automations. Their iteration cycle is fast — write a skill, open a test conversation, refine. No build step or deployment pipeline. The feedback loop is between the expert and the agent, directly.

Why this matters for adoption

If AI adoption requires hiring ML engineers for every team, it won't scale. There aren't enough ML engineers, and even if there were, the knowledge transfer bottleneck would still throttle every project. But if AI adoption requires domain experts to write markdown, it scales across every team. The SOC team writes security skills. The finance team writes reconciliation skills. The sales team writes deal review skills. Each team encodes their own expertise, on their own timeline, without waiting in an engineering backlog.

The SOC analyst knows that a 3am login from a service account isn't suspicious — it's a scheduled batch job. The sales manager knows that a quiet period in December doesn't mean a deal is stale — it means the buyer's company is in holiday freeze. These nuances are the difference between a useful agent and a noisy one. They only come from the people who live in the domain. And now those people can encode them directly.

The skills era doesn't replace engineers. It frees them from being the bottleneck. The SOC analyst writes the methodology. The sales manager defines the process. The compliance officer documents the rules. The engineer builds the infrastructure once — the runtime, the connections, the platform — and gets out of the way. Everyone wins. And the organization gets AI adoption that actually scales — not because they hired more engineers, but because they unlocked the people who already knew how the work gets done.