Skip to main content

​
Direct answer

Grantex supplies verifiable, delegated tool authority for AgenticOrg’s governed business cases. The AgenticOrg source runtime requires one active tenant role agent, a registered provider read-tool manifest, an exact local case-purpose allowlist, and a valid delegated grant before every provider call. A missing or denied check stops the provider call. Case decisions and analyst review remain human actions in AgenticOrg; an agent grant does not approve a case. This describes repository source, not an assertion that a particular hosted tenant has the feature enabled or that the latest main commit is deployed. Check the deployed revision and the tenant’s governed_cases.enabled flag.

​
Responsibility boundary

The current published Python dependency is grantex==0.5.1. It does not enforce token-level purpose or per-case caps for this flow. A pooled run token is not bound to one case. Newer Python 0.6.0 and TypeScript 0.7.0 source trees include general purpose and decision-aware APIs, but they are not the published SDKs at this guide’s registry check on September 24, 2026, and AgenticOrg has not wired their case context into enforcement. Source presence alone is not a production control. See Release Status.

​
Operator setup

  1. Review the selected provider’s manifest and allow only the read tools the business-underwriter and screening-disposition roles need.
  2. Register exactly one active, shared tenant agent for each role in AgenticOrg. Verify each stored Grantex agent ID and derived scope set.
  3. Set each role’s exact case_purposes list and provision a root grant that covers the registered tools. Keep credentials in a secret manager.
  4. Configure a reviewed case policy and provider. The bundled mock provider is for local and test environments, not production verification.
  5. Run denied-path tests for missing role, wrong purpose, missing grant, revoked grant, undeclared tool and provider failure before enabling the tenant flag.
  6. Confirm the deployed SHA and operator logs before describing the flow as available to users.
AgenticOrg’s case lifecycle and grant-enforcement runbook are the implementation and operations sources of truth.

​
SDK and MCP boundary

Machine-safe submit, list, read and investigation-scheduling methods for the AgenticOrg Python and TypeScript SDKs are proposed in AgenticOrg PR #1401. At this guide’s September 24, 2026 check, they are not in AgenticOrg main or its published 0.3.0 client packages. Evaluate them from that PR’s source branch until it is merged, released and verified separately. Scheduling an investigation is not proof it succeeded; inspect the later case state. AgenticOrg’s MCP server advertises general agents-as-tools, not the governed case roles. Grantex MCP transport authorization and tool authorization are separate from AgenticOrg’s human case-decision path. Neither MCP discovery nor an agent token can stand in for a signed-in person or a verified decision grant.

​
Future integration gate

Token-level purpose, decision and cap features should be enabled only after a published SDK is installed, its API is pinned, AgenticOrg passes the case context to enforcement, and cross-tenant, replay, expiry, revocation, and per-case budget tests pass. Do not infer those guarantees from a dependency version bump alone.
Last modified on September 24, 2026