gen-z-developers.sgit.ai → The graph → Ideas → Zoom into an agent's behaviour policy and you find the business logic, which only the business can write

claim candidate goes to: this-edition V villager

Zoom into an agent's behaviour policy and you find the business logic, which only the business can write

The first rules anybody writes for an agent are mechanical and the same in every company: do not send, only draft; do not delete; use your own account. A few questions in (which drafts may it send, can it mention a price, can it chase an invoice finance has not approved, can it write to a client in dispute) you are describing the business, in layers with different owners: the function, the process, the relationship, and what the company is for. Vendors stop at the mechanics by the shape of the problem, since a vendor that models each customer's business becomes a consultancy; the business layers are the customer's to write, and written together with skills (a skill says how, a policy layer says what is allowed, who owns the rule and what stands in the way) they are the business codified for an agent, which is what lets a company hand it real work and scale.

Decided by. Nobody yet: a candidate for Dinis to read, comment on and decide (keep, rewrite, merge, cut, article first, later, not doing it).

Note. The article's own five readers flag that its front matter overstates the body: 'the only way to describe agent behaviour at the granularity a business actually runs at' is unsupported; the body says only that a fractal structure is the one Dinis found that can hold it. The register should not say 'only way'. The firm, its rules and its counts are fictional on purpose.

Where it comes from

What it answers in the 2018 book

Where it goes

Chapter Controlling your agent: RiskMandate, part Build it without a server (drafting); topic Controlling your agent: mandate, reach and hope versus enforcement.

Other ideas proposed for the same chapter: Mandate, reach and the gap: hope versus enforcement, Code is a liability; the future is the smallest code that does the job, Learning to hack is still how you learn how things work: draw the line where the attacker is, The secret goes from the drop into the tool, never into the chat, Security experience is what lets you ship with known gaps: list them, match them to the reader, say what would change the call, The agent behaviour policy is the due diligence document: a buyer reads the blast radius off it, and its absence says the most, A vault per conversation and per job: a leaked key exposes one small thing, not an inbox, The desktop is the barrier, not the model: prompt injection is not solved, so the box has to hold, Reach is a computed value, and new capability lands as excess, never as new authority, Who can pull the plug: an agent that cannot be stopped is riskier than one that can, A third input: a behaviour policy beside the system prompt and the prompt, which the vendor acknowledges, enforces where it can and answers for, Models do not separate code from data, so a rule in the prompt can be argued with by an email, Aviation and payments got safe when the rule, the liability and the business model pointed the same way, Software was the law: the rule the screen enforced by omission is no longer enforced once an agent calls the API, Every rule lands in one of three states: backed by a control, governed by an accepted risk, or resting on hope, Write down what your agent can reach in twenty minutes: list its tools, say what you wanted it for, write the gap.

Node idea:the-policy-is-the-business-logic in graph.json; see it in the graph. Source: admin/content/graph/ideas.json.