Agenticorg

AgenticOrg is an Apache-2.0 enterprise AI agent platform for building, running, and governing agent workflows across finance, HR, marketing, operations, back office, communications, and bounded agentic-commerce use cases.

Ownership: AgenticOrg is owned by Orchestrum Technologies LLP.

Inventor / Owner: Sanjeev Kumar

Contact: sanjeev@orchestrum.in | mishra.sanjeev@gmail.com

See the canonical ownership and contact statement and NOTICE.

Website | Application | Playground | User manual | Technical documentation | Current product status | Security policy

Source of truth

Live product totals and the deployed product version are published by the public product facts endpoint:

GET https://app.agenticorg.ai/api/v1/product-facts

The response contains version, agent_count, connector_count, and tool_count. Do not copy those values into documentation, page copy, or tests: they are computed from runtime registries and can change independently of a documentation release. The version declared for source builds is in pyproject.toml.

Billing limits and list prices come from core/billing/catalog.py. Production deployment behavior comes from scripts/deploy_cloud_run.sh.

Current release at a glance

The production platform currently includes governed agent/workflow execution, document ingestion with scanned-document OCR, signed Twilio voice with provider-managed STT/TTS, tenant-scoped browser RPA, Python and TypeScript SDKs, MCP/A2A surfaces, and the bounded Shopify-to-OACP commerce runtime. See the current product status for the exact shipped, configuration-dependent, and not-shipped boundaries.

External actions remain explicit. A voice provider, connector, browser script, buyer channel, payment rail, merchant system, or POS path is usable only when the target tenant has the required credentials, scopes, configuration, and provider approval.

Governed business cases

The repository includes a tenant-gated business onboarding case workflow with read-only provider investigation, a cited memo, deterministic policy scoring, screening dispositions, human review, and an auditable hand-off. Provider calls are refused unless the active role agent, registered tools, exact local case purpose, and delegated grant all authorize the call. This case-specific check is strict even if general tool enforcement is in off or warn mode.

The currently published grantex==0.5.1 does not verify a case purpose in the token or enforce a per-case cap. The role's case_purposes list is a local AgenticOrg control, and pooled grants are not bound to one case. Decision and analyst actions still require a signed-in human; API keys, agent tokens, and MCP tools cannot act as that human. The case runtime is off for a tenant until enabled and configured. This source description is not a claim that a particular hosted deployment has enabled the workflow. See the case lifecycle and setup, grant-enforcement runbook, and decision requests.

Voice, email, OCR, and browser RPA can be exercised together before release with the Docker-backed local multichannel simulation. It uses fresh PostgreSQL, local Mailpit delivery, real Tesseract, and optional real Playwright Chromium while keeping paid calls and production mutations off.

The dashboard's Recent Activity queries audit records. The separate internal live-feed pipeline persists events per tenant when published and can replay them by sequence after a WebSocket interruption, but operational event writers are not yet wired to that pipeline. Its browser component exposes connection/catch-up status without raw payload display; it is not mounted as the dashboard's live stream. Broker reconnection, bounded socket fanout, and periodic credential revalidation are covered by local tests. Production latency, throughput, and availability remain unmeasured. The activity delivery guide explains the boundary. The scale and resilience assessment tracks remaining connection-scale, load, and restore work; the recovery guide separates planned targets from proven production controls.

What is in this repository

A source definition is not evidence that a specific tenant has connected the provider or enabled write access. The Connectors page now separates registration from configured credentials and a recent, stale, failed, or missing health check. That evidence does not verify provider scopes, API contract coverage, sustained sync, or an error budget. Connector actions still require approved credentials, scopes, policies, and provider availability.

Capability status

Implemented in the platform

• Agent definitions and tenant-created agents
• Agent and workflow execution through authenticated APIs
• Human approval queues and configurable escalation conditions
• Audit records for governed runtime activity
• Prompt templates, organization structure, and role-aware application views
• Native connector definitions and a scoped tool gateway
• Public A2A and MCP discovery with authenticated execution paths
• Python and TypeScript client packages plus an MCP server package
• Hosted billing limits and checkout integration
• OACP commerce configuration, Shopify read-only sync, artifact caching, buyer channels, and safe handoff preparation

Configuration-dependent or provider-gated

• LLM calls require a configured supported model provider or a local model runtime.
• Each connector requires provider credentials, tenant authorization, and the relevant scopes. Follow the connector setup guide for native registry names, credential fields, health checks, and the rollout-gated catalog prefill. A registered row is not proof of a live provider connection.
• Composio is an optional integration gateway; its catalog is not the same as the native connector registry.
• Document OCR ships with Tesseract, Poppler, and LibreOffice in the production image. See Knowledge ingestion.
• The production voice path uses signed Twilio webhooks with provider-managed STT/TTS and encrypted transcript storage. See Voice runtime.
• Jev/System One support is implemented as an advisory, shadow-ready integration, but TypeSafe enrollment is currently closed to new users. Production remains off until TypeSafe access is granted and a measured evaluation is approved. See Jev integration.
• The public evaluation page exposes a read-only Jev shadow plan: synthetic corpus coverage, bounded sampling and budget controls, and explicit review gates. It does not call Jev or enable active routing.
• The measured Jev shadow runner is explicit and local: python scripts/run_jev_shadow_evaluation.py --dry-run; --live requires a TypeSafe-issued TYPESAFE_API_KEY, bounded gates, and an operator-approved output path. Do not invent, commit, or paste a key into the repository.
• Browser automation includes tenant-scoped scripts, schedules, durable history, and approved-domain egress controls. A run remains an explicit external action. See RPA runtime.
• Outbound notifications and local-model profiles require their supporting services.
• SSO, SCIM, enterprise support, and custom SLAs depend on plan and deployment configuration.
• WhatsApp, Telegram, payment-provider, bank, POS, and merchant-system flows require provider setup and verified callbacks or adapters.
• WooCommerce, ERP, PIM, OMS, WMS, custom commerce APIs, and additional payment rails can be recorded as adapter-ready configuration but are not represented as active execution paths until an approved adapter exists.

Explicit non-goals and boundaries

• OACP artifacts do not create orders, reserve inventory, create mandates, capture payments, issue refunds, or prove a paid state.
• AgenticOrg does not replace the merchant, bank, payment provider, POS, or SaaS system as its source of record.
• Cached commerce evidence can support an answer or a prepared handoff; provider-owned execution must be confirmed by the provider.
• A connector listed in source is not proof of a live customer integration.
• Example workflows and editorial content are not performance guarantees.
• Security controls in the repository are not a claim of third-party certification.

How the runtime fits together

Browser or SDK
    |
    v
React 19 application / FastAPI API
    |
    +-- Authentication, tenant context, roles, and scopes
    +-- Agent registry and LangGraph execution
    +-- Workflow engine, schedules, and approval queues
    +-- Tool gateway and connector adapters
    +-- Audit, evaluation, observability, and cost records
    |
    +-- PostgreSQL / Cloud SQL
    +-- Redis
    +-- GCS or compatible object storage
    +-- Configured LLM and external service providers

The managed production path runs separate API and UI services on Google Cloud Run. Artifact Registry images are commit-pinned, migrations can run before rollout, and traffic movement is explicit. Legacy Kubernetes material is not the current production path.

OACP commerce boundary

AgenticOrg owns the buyer and seller agent runtime around OACP-backed commerce. Grantex owns trust authority, protocol and policy governance, canonical artifacts, artifact verification, and adapter authority. Shopify and merchant systems remain operational sources of record. Pine Labs Plural/P3P, banks, POS systems, and payment providers own their execution rails.

The current supported source path is:

1. A merchant saves tenant-, merchant-, store-, and seller-agent-scoped configuration.
2. AgenticOrg stores Shopify credentials through the approved custody path.
3. AgenticOrg performs read-only Shopify Admin GraphQL sync.
4. Public-safe evidence is submitted to the configured Grantex authority path.
5. Issued OACP artifacts are cached with freshness, scope, risk, and revocation posture.
6. Buyer surfaces answer from valid artifacts and disclose source and freshness.
7. Purchase intent becomes a non-executing provider, merchant, or POS handoff, or a fail-closed blocker.
8. Only a verified provider or merchant callback can confirm the external outcome.

Start with docs/oacp/README.md and the runtime launch closure PRD.

Requirements

• Python 3.12 or newer
• Node.js 20 or newer
• Docker with Docker Compose for local PostgreSQL and Redis
• At least one supported LLM provider key, or a configured local model runtime, for model-backed execution

The UI currently uses React 19. Dependency versions are declared in pyproject.toml and ui/package.json.

Local development

Clone and configure the repository:

git clone https://github.com/mishrasanjeev/agentic-org.git
cd agentic-org
cp .env.example .env

Install the platform and development extras:

python -m venv .venv
python -m pip install -e ".[v4,dev]"

Start local dependencies:

docker compose up -d postgres redis minio

Run migrations and the API. AGENTICORG_ENV must be in the shell environment, not only in .env: the credential vault reads the process environment, and outside a local, dev, development, test or CI runtime it refuses to start without a real vault key.

export AGENTICORG_ENV=development
python scripts/alembic_migrate.py
uvicorn api.main:app --host 0.0.0.0 --port 8000 --reload

In another terminal, install and run the UI:

cd ui
npm ci
npm run dev

Do not use example secrets in staging or production. Configure real secrets through the approved secret-management path.

Optional Compose profiles include local CPU/GPU model runtimes and supporting RAG or voice services. Review docker-compose.yml before enabling a profile because hardware, images, and credentials vary by feature.

Public API and protocols

Application API routes are mounted below /api/v1, except the standard root A2A Agent Card discovery path.

Interactive OpenAPI documentation is available from the API service when enabled by the deployment. The detailed route inventory is maintained in docs/route_inventory.json, and narrative API documentation is in docs/api-reference.md.

An external buyer agent need not run on AgenticOrg. The merchant can issue a revocable, scope-bound buyer credential for any A2A v1 HTTP+JSON client, while seller answers remain non-binding and sourced from the OACP cache. See the A2A interoperability guide for the exact identity limits, SDK calls, migration/ingress requirements, and unsupported transports. This repository implementation does not imply that a named buyer platform has installed or endorsed AgenticOrg.

Python SDK and CLI

See sdk/README.md.

pip install agenticorg
agenticorg agents list
agenticorg a2a card

SDK 0.4.0 covers agents, workflows, connector diagnostics, knowledge/OCR, voice, RPA, local bridges, and the seller-commerce runtime. External-action methods such as outbound calls, RPA runs, connector sync, and bridge routing remain explicit calls and still require tenant authorization. Server features may require a newer deployment than the installed client, so consumers should check package and server release notes.

TypeScript SDK

See sdk-ts/README.md.

npm install agenticorg-sdk

The TypeScript 0.4.0 resource surface mirrors the Python runtime coverage, including knowledge/OCR, voice, RPA, bridges, and commerce preparation APIs.

MCP server

See mcp-server/README.md.

npx agenticorg-mcp-server

The MCP package exposes governed AgenticOrg agent and commerce discovery surfaces. It does not grant an MCP client unrestricted access to every connector action.

For the reverse direction, Connectors > Remote MCP registers a tenant-owned HTTPS Streamable HTTP server with encrypted bearer credentials, discovers its tools, and shares the persisted catalog with agent selection and runtime dispatch. Reviewed read tools can execute subject to grants and action policy; write tools remain contained. Discovery is not proof of every upstream provider capability. See the connection, review, probe and agent-run workflow.

Pricing and limits

The hosted plan source of truth is the typed PUBLIC_PLAN_CATALOG in core/billing/catalog.py. A compatibility view in core/billing/limits.py is derived from that catalog.

The repository is Apache-2.0 licensed. Infrastructure, model-provider, external API, payment-provider, and support costs are separate from the software license.

Security and governance

The codebase includes:

• Tenant, role, and scope checks around protected API operations
• Configurable human approvals and confidence or policy gates
• Scoped connector tools and a centralized tool gateway
• Secret-reference patterns for connector and cloud credentials
• Configurable PII redaction before model calls and in logs
• JWT verification through PyJWT with cryptographic support
• Rate limiting, security headers, and authentication-state controls
• Dependency, static-analysis, container, and regression security checks
• Audit and observability records for governed operations
• Fail-closed OACP freshness, revocation, and provider-boundary checks

Production security depends on correct deployment configuration, key custody, provider settings, tenant policies, and operational monitoring. Report vulnerabilities through SECURITY.md; do not open a public issue for a suspected vulnerability.

Testing

Backend:

pytest

Focused backend checks can be run by directory or file:

pytest tests/unit
pytest tests/regression
pytest tests/connector_harness

Frontend:

cd ui
npm ci
npm run lint
npm run typecheck
npm test
npm run build

Browser tests:

cd ui
npx playwright test

Playwright suites require the target application and any documented test credentials or fixtures. CI workflow files under .github/workflows are the source of truth for which suites run on each event; the README does not claim that every E2E suite runs on every push.

Production deployment

The current managed rollout helper targets Google Cloud Run:

bash scripts/deploy_cloud_run.sh --sha <commit-sha> --yes

Useful modes include:

bash scripts/deploy_cloud_run.sh --sha <commit-sha> --skip-build --with-migrations --yes
bash scripts/deploy_cloud_run.sh --sha <commit-sha> --skip-build --traffic preserve --yes
bash scripts/deploy_cloud_run.sh --sha <commit-sha> --dry-run

The helper requires a clean checkout at the exact deploy SHA, stages revision-specific images, verifies image and commit metadata, supports migration-first deployment, probes health, and moves traffic according to the selected mode. Read the script help and docs/deployment.md before using production credentials.

Default script configuration places Cloud Run services in asia-southeast1 and Artifact Registry in asia-south1. Both are configurable. Older Kubernetes material is retained only for historical or alternative deployment context.

Repository map

api/                 FastAPI application and versioned routes
auth/                Authentication and authorization middleware
core/                Agent runtime, models, billing, commerce, and orchestration
connectors/          Native connector implementations and framework
workflows/           Workflow definitions and runtime helpers
sdk/                 Python SDK and CLI
sdk-ts/              TypeScript SDK
mcp-server/          MCP server package
ui/                  React 19 application and public web assets
migrations/          Database migrations
observability/       Metrics, tracing, and logging helpers
tests/               Backend unit, regression, security, and integration tests
ui/e2e/              Playwright browser tests
docs/                Product, architecture, operations, and protocol documentation
scripts/             Validation, migration, release, and deployment helpers

Search and answer-engine assets

The public site includes conventional search and answer-engine discovery assets:

• robots.txt
• sitemap.xml
• llms.txt
• llms-full.txt
• Per-route titles, descriptions, canonicals, social metadata, and structured data
• Crawlable blog, resource, product, protocol, solution, trust, and legal pages

The two llms files are generated by ui/scripts/generate-llms.mjs. They are supplemental machine-readable navigation documents, not replacements for crawlable HTML, accurate structured data, robots controls, or the sitemap.

To refresh the tracked sitemap and llms copies plus route JSON-LD CSP hashes:

cd ui
npm run seo:sync
npm run seo:verify

Documentation

• End-user manual: first agent, everyday operations and BFSI playbooks. The UI serves this same Markdown content at agenticorg.ai/docs, with full-text search, visual process flows, print-friendly guides and mobile navigation. The docs.agenticorg.ai alias has configured Cloud DNS and managed HTTPS; its hosting and verification instructions live in the documentation runbook.
• Functional BFSI coverage and open gaps shows what is implemented, partial or unavailable, with verification scenarios and product boundaries.
• Public BFSI capability status gives readers a plain-language summary of the same assessment, including unfinished work.
• Documentation site publishing and subdomain runbook
• Documentation home
• Current product status
• Architecture
• API reference
• Deployment
• Knowledge ingestion and OCR
• Local voice, email, RPA, and OCR simulation
• Voice runtime
• RPA runtime
• OACP runtime documentation
• External A2A buyer and seller access
• Local synthetic seller and independent A2A buyer demo
• Guided merchant-to-external-buyer A2A commerce journey
• Production smoke runbook
• Testing guide
• Python SDK
• TypeScript SDK
• MCP server
• Changelog
• Roadmap

The documentation home labels current, configuration-dependent, historical, and target-design material. Dated audits, old PRDs, and incremental implementation reports remain useful history, but they do not override current code, OpenAPI, runbooks, retained release evidence, or live product facts.

Contributing

Read CONTRIBUTING.md and CODE_OF_CONDUCT.md. Keep pull requests focused, add tests for behavior changes, and update generated public documentation when a source-of-truth field changes.

License

AgenticOrg is licensed under the Apache License 2.0.