What should a coding agent be structurally unable to do in a CRM?
I am building Accordo, an open-source framework that coding agents use to build
custom CRMs as code the customer owns.
The first design question I expected was: what should Claude Code or Codex be
able to generate?
The more useful question turned out to be the inverse: what must the agent be
unable to do, even if a later prompt asks it to?
A CRM touches prices, discounts, signatures, pipeline state and commitments. A
prompt that says "always ask a human first" is helpful, but it is not a boundary.
Prompts change, context is truncated, and a new tool can bypass the path the
instruction expected.
So I am treating refusals as product surface. In Accordo, a versioned policy can
put a quote into pending_approval; an agent actor calling the approval action
gets 403 HUMAN_APPROVAL_REQUIRED; a named test fails if that stops being true.
The agent can prepare the decision and assemble the evidence. It cannot become
the approver because it generated the surrounding app.
Accordo already enforces this across its supported development runtime. The actor
is currently asserted rather than authenticated, so a coding agent taking the
application to production must include authentication, tenancy and RBAC before
network exposure. Making that deployment envelope explicit lets the agent plan
the hardening instead of discovering it after generation.
The exact capability and its current boundary are published together here:
https://accordo.dev/answers/can-an-agent-approve-a-deal-or-discount.html
The underlying test and claims are public:
For founders building agent-authored software: which verbs in your product need
to be structurally unavailable to the agent? Approve, publish, pay, send, delete,
sign, change policy — or something else?
Treating refusals as product surface is exactly right because what an agent "should be unable to do" is really a measurement system for organizational risk. You're not preventing bad behavior - you're measuring where the organization has to stay in control.
The structural boundaries you describe (403 HUMAN_APPROVAL_REQUIRED) are measurement points. They're forcing the system to measure "did a human make this decision" instead of trying to measure it through prompts that can be forgotten or overridden.
The leverage is that by making boundaries structural, you're also making the enforcement measurement automatic. Every approval that shouldn't happen gets tested. Every time the agent tries to cross the line, the organization gets data about where the line actually is.
Most organizations building with agents measure "did the agent follow the instruction" when they should measure "are the constraints still holding." Your framework essentially turns constraints into unit tests. The agent can't accidentally bypass a 403 because it's not about instruction compliance - it's about whether the HTTP response is correct.
For founders thinking about this: start by asking not "what should the agent never do" but "what do I need to measure to know the agent is still operating safely." Then make that measurement structural, not prompts.
Treating refusals as product surface is the right inversion. A prompt that says "ask a human first" dies the moment context truncates or a new tool opens a side door, so the boundary has to live in policy and return 403, with a test that fails if that ever softens. For a CRM I would put approve, sign, publish, pay, and change policy in the structurally unavailable set, and let the agent prepare evidence and draft the decision without ever holding the verb. The remaining risk is the actor assertion you already call out: if the agent can mint a human identity at deploy time, the 403 is theater.
The distinction between what an agent can generate and what it can never be allowed to do is a much more consequential design question than it initially appears.
The fact that you’re treating those boundaries as part of the product itself makes this especially worth watching.