Portable Agents Need Portable Behavior#

A team ships a support agent. The behavior lives in a string.

system_prompt = "You are a helpful support assistant..."

It's the fastest way to get an agent working, and at prototype time it's usually the right call. You have one app, one runtime, one team, and one place to patch when something goes wrong.

The trouble starts when that behavioral posture needs to exist somewhere else. A second agent should sound the same way. A template should ship with the same communication defaults. A teammate wants to review the escalation rules without reading application code. An SDK app wants to inspect what behavioral contract an installed agent expects before trusting it. The system prompt that felt convenient starts acting like a hidden dependency.

Then the prompt grows. Six months of edge cases, formatting rules, persona notes, failure modes, and examples later, it stops looking like a prompt and starts looking like a junk drawer.

Portable agents need portable behavior.

The app-local system prompt problem#

Most agent behavior starts as app-local prompt text because that is how most useful systems start.

It shows up in familiar forms:

system_prompt = "You are a helpful support assistant..."
agent_config.instructions = "Be concise, escalate when..."
prompt.md
app/prompts/support-agent.txt
framework-specific role configuration

None of those are wrong. They are the fastest path to a working prototype. The problem is what happens after the first prototype succeeds.

One of the better concrete examples comes from a team that spent six months growing a system prompt to roughly 4,000 tokens. It accumulated edge-case handling, formatting rules, persona instructions, fallback behaviors, and a dozen few-shot examples. Then a junior engineer rewrote it in an afternoon at about 200 tokens. It scored four points higher on their own eval suite, ran roughly 40x cheaper, and was noticeably faster. Their postmortem line gets to the heart of the problem: “long prompts grow by accretion, not by design. Every failure mode that surfaced in QA contributed a paragraph.”[1]

The token count is a symptom. The real problem is that behavior has no artifact boundary, so every fix gets appended to the same blob because there is nowhere else for it to go.

The failure modes are easy to recognize:

a second agent needs the same tone and escalation posture and has to infer it from another team's code
a template wants to ship a default communication posture, but there is no declared posture to attach
a reviewer wants to inspect boundaries or constraints and has to read prompt prose to find them
an SDK app has no metadata to load because behavior only exists as a string buried in application code
the same behavioral intent gets retyped, slightly differently, across several apps

This isn't an edge case. Prompt engineering already accounts for an estimated 30 to 40 percent of AI development time on production teams, and teams running more than ten prompts in production call versioning one of their top three operational challenges.[5]

Behavior that only makes sense inside one app has a name: app-local prompt glue.

A system prompt is not a packaging format#

Prompt engineering still matters. It did not stop mattering. Teams still need to write good instructions, shape outputs, set boundaries, and tune behavior to fit real workflows. The claim here is narrower: a single opaque prompt string is a weak packaging boundary.

Maintainability is the obvious cost. The less obvious one is execution reliability.

Research on multi-instruction following makes this uncomfortable in a useful way. The “curse of instructions” result shows that instruction-following accuracy compounds badly as instructions pile up. If a model follows any single instruction correctly 95 percent of the time, ten simultaneous instructions succeed together only about 60 percent of the time in theory. Real measurements are worse: GPT-4o achieved just 15 percent success with ten simultaneous instructions in the same prompt, while Claude 3.5 Sonnet reached 44 percent.[2]

Cramming role, tone, formatting rules, safety boundaries, edge cases, and exceptions into one blob doesn't just make the text harder to review — it lowers the odds that all of it gets followed at once. That's the real cost of the prompt-monolith pattern.

A prompt blob may contain all of these:

role · goals · audience · tone · verbosity · formatting rules
escalation rules · safety boundaries · domain assumptions
tool usage hints · policy notes · examples · constraints

Mixed together in one string, none of them is separately inspectable, separately diffable, or separately reusable.

The packaging distinction follows directly:

Prompt engineering = crafting behavior in text
Instruction Profiles = packaging durable authored behavior as structured metadata

A prompt can tell one runtime how to behave. A Profile can tell another system what behavior an agent expects.

That is the missing boundary.

Structured behavior metadata, packaged separately from execution#

What matters here is giving durable behavior a shape other systems can actually read.

Instead of one paragraph, behavior becomes explicit fields:

identity · objectives · principles · audience
communication (tone, verbosity, guidelines, vocabulary)
boundaries · declared constraints · compatibility hints

Splitting behavior into fields like this changes what other systems can do with it. An SDK can load role without parsing prose. A reviewer can scan boundaries without reading the whole package. A diff on verbosity is a one-line contract change instead of a paragraph rewrite. A template can declare a behavioral dependency the same way it declares a tool or knowledge dependency.

There is also a deeper reason “identity” deserves to be a real field instead of prompt trivia. Anthropic’s Persona Selection Model argues that these systems do not have one fixed behavior. They learn to simulate many possible characters during training, and post-training tends to reinforce a particular assistant persona.[3] Skip the philosophy debate — the packaging insight is what matters: if role and posture already shape how an agent behaves, authored identity belongs in the dependency graph like anything else worth naming and reviewing directly.

None of that makes a Profile a runtime, though.

Profiles are not:

a tool · a Skill · a workflow · a harness
a prompt merger · a policy engine · an execution runtime
a guarantee the agent will always behave correctly

Behavior and execution are different concerns: Tool code performs actions; a Profile describes authored behavior. It's one of the strongest parts of the design — a Profile makes behavior visible without pretending to own how every runtime applies it.

Behavior becomes reusable when you can inspect its shape, not just paste its text.

Why portable AI agents need portable behavior#

An agent is a composition of artifacts and expectations, not just a tool list plus a prompt.

If an agent depends on a tool, that dependency is visible. If it depends on a Skill, the procedure is visible. If it depends on Knowledge, the context is visible. If it depends on Memory, the durable state contract is visible. If it depends on a behavioral posture, that dependency should be visible too.

The artifact model is simple:

Tool = action
Skill = procedure
Knowledge = context
Memory = durable state contract
Profile = authored behavior
Agent = composition
Template = starter

The pattern shows up anywhere an agent's behavior needs to travel:

an agent handling live support conversations depends on a Profile defining tone, escalation posture, audience, and boundaries
an agent coordinating during an incident depends on a Profile defining concise communication, operational caution, and handoff behavior
an agent reviewing pull requests depends on a Profile defining review posture, approval boundaries, and repository communication style

If the Profile doesn't travel with the agent, the receiving app has to guess: what role matters, what audience is assumed, which constraints were intentional, what the runtime should avoid claiming, and which tone is authored behavior versus whatever the current app happened to write.

This gets more urgent as agent counts grow. Gartner projects the average Fortune 500 enterprise will run roughly 150,000 AI agents by 2028, up from fewer than 15 in 2025.[6] At that scale, “can we tell what each one expects?” matters more than “can we build one?”

The ecosystem already knows this pattern. A2A’s Agent Card makes capabilities and interface assumptions explicit instead of forcing callers to infer them from behavior.[4] Instruction Profiles apply the same instinct to authored posture. They are not capability cards. They are behavior contracts.

If behavior affects how an agent acts, it should be visible in the artifact graph.

How AgentPM Instruction Profiles work#

Instruction Profiles in AgentPM package authored behavior as structured metadata instead of prompt prose.

At the manifest level, that means kind: "profile" with a required top-level profile object. The structured fields cover exactly the durable behavior layer:

identity · objectives · principles · audience
communication (tone, verbosity, guidelines, vocabulary)
boundaries · declared constraints · compatibility hints

The CLI supports the whole artifact flow:

agentpm init --kind profile
agentpm lint
agentpm publish
agentpm install @namespace/name@version

Agents and Templates can depend on a Profile the same way they depend on a Tool or a Skill: it resolves, installs, and locks alongside the rest of the dependency graph.

The rest of the stack lines up with that model. Profile packages publish, search, and display as a first-class kind next to Tools, Skills, Knowledge, Memory, Agents, and Templates, with detail pages that show identity, objectives, communication posture, and boundaries. SDKs can load an installed Profile directly — loadProfile() in Node, load_profile() in Python — and get back structured metadata, not a compiled prompt and not README text reinterpreted as instructions.

The restraint matters as much as the feature list. Instruction Profiles do not compile a system prompt, choose which Profile is active, merge several Profiles together, or enforce declared constraints at runtime. A required constraint is declared author intent, not an execution guarantee. The host app, framework, or harness still decides how to apply the Profile.

None of that is accidental. Packaging makes behavior visible and reusable without requiring AgentPM to control how any given runtime executes it. That's the goal, not a limitation.

The full model is clearer now:

Tools package actions.
Skills package procedures.
Knowledge packages context.
Memory packages durable state contracts.
Profiles package authored behavior.
Agents compose those artifacts.
Templates bootstrap working systems from them.

Portable agent systems need more than portable tool calls. They need portable procedure, portable context, portable memory shape, and portable behavior. If role, objectives, communication posture, boundaries, and constraints affect how an agent acts, they should not be trapped inside one app-local prompt string.

Sources#

The 200-Token System Prompt That Beats Your 4000-Token One. https://tianpan.co/blog/2026-05-02-200-token-system-prompt-beats-4000-token-one
Curse of Instructions: Large Language Models Cannot Follow Multiple Instructions at Once. https://openreview.net/forum?id=R6q67CDBCH
The Persona Selection Model. Anthropic Alignment Science Blog (2026-02-23). https://alignment.anthropic.com/2026/psm
Agent2Agent (A2A) Protocol Specification, Agent Card. https://a2a-protocol.org/latest/specification/
Prompt Versioning: Best Practices for AI Engineering Teams. https://www.getmaxim.ai/articles/prompt-versioning-best-practices-for-ai-engineering-teams/
AI Agent Sprawl: Causes, Risks, Fix. https://atlan.com/know/ai-agent/agent-sprawl/