Your agent doesn't need more tools — it needs a job description.

I've been writing a series about what it takes to make software agent-ready — the translation layer, permissions, approvals. This is the part that ties it to how teams actually work: roles and business logic. Roles are what let you stop configuring agents one by one. A support role bundles up search-records, draft-response, escalate-ticket. A billing role bundles read-invoice and issue-refund-under-threshold. You define it once, hand it to any agent — human, internal copilot, third-party model — and the permission boundaries travel with it. Change the role, and everything wearing it updates at once. Business logic is the piece most agent setups skip entirely. Companies don't run on "create ticket." They run on rules like: refund under $50 approves itself, over $50 needs a manager; enterprise tickets route to the senior queue; nothing ships until the order is paid. If your agent has to learn that from a prompt, it's already lost. The playbook should be part of what the software exposes, not something the agent improvises around. That's the full picture as far as I'm concerned. Actions are the vocabulary, permissions are the boundaries, roles are the job descriptions, business logic is how the company already runs. Put it together and the agent stops improvising and starts operating the way you intended. Which of your team's unwritten rules would you encode first?