Jeeva

The action layer of the published architecture states four hundred plus connectors, described as API connectors making real changes in real systems, and a named runtime component confirms workers operate across CRM, email, support, identity and business systems.

Named in the worker walkthroughs and product pages: Salesforce, HubSpot, Zendesk, Gmail and Outlook, calendars, and an applicant tracking system, with a published integrations page. Workers act rather than only read: they provision access, write CRM records, resolve and respond to tickets, post invoices to accounting and send from connected mailboxes.

Sourcejeeva.ai architecture layer L3, integrations page and worker process walkthroughsread 2026-09-01

The platform carries the control flow and the vendor names the mechanisms: the cognition layer is described as a builder agent that designs and a worker agent that executes, which plans, branches and self-heals, so branching and recovery are both stated rather than implied.

A Planning Engine is a named runtime component with workers determining next steps and coordinating execution automatically, and Continuous Execution runs work around the clock. Six worker types ship with documented multi-step processes, for example ingest ticket, query knowledge base, draft resolution, send response, and detect anomaly, triage and root cause, execute runbook steps, resolve and post-mortem. Workers are deployed by describing them in natural language with no node diagrams.

Sourcejeeva.ai architecture layer L2 and worker process sectionsread 2026-09-01

Grounding runs mostly on external data: enrichment draws from a large number of data streams to fill in verified contact details, firmographics, funding history, hiring signals and news, which grounds outreach on the prospect rather than on the customer's own knowledge. On the customer's side, query knowledge base appears as a documented step in the support worker's process and the memory layer names durable knowledge. No ingestion path or retrieval interface is documented; nothing describes uploading documents, connecting a knowledge source, or how retrieval is performed.

Sourcejeeva.ai enrichment page, worker process and architecture layer L4read 2026-09-01

Oversight is a configurable control rather than a property of one workflow. Human Approvals is a named component of the worker runtime, described as reviewing sensitive actions while routine work stays autonomous. Policy thresholds are documented as the escalation trigger for the support worker, the finance worker routes exceptions for approval before posting, and a dedicated FAQ entry covers what controls a customer has over worker behavior. The governance layer adds permissions and safeguards built into every action.

Sourcejeeva.ai worker runtime and governance layer sectionsread 2026-09-01

Jeeva documents both access controls and a compliance posture. For access, enterprise readiness pages cover single sign on and identity federation and role based access control with least privilege, RBAC is stated as defining and enforcing every permission level, and SSO comes on the Enterprise plan.

The Vanta hosted trust center at trust.jeeva.ai lists SOC 2, GDPR and ISO 27001:2022, with SOC 2 Type I and Type II reports, an ISO 27001 audit report, a penetration test report and a sub-processor list, and a DPA is published on the main site. The enterprise page, however, says SOC 2 readiness beside the certificate badge.

Sourcejeeva.ai/enterprisereadyread 2026-10-01

Run-level visibility reaches the steps and the tools. A section headed execution visibility across digital workers sits above worker walkthroughs that show the sequence a run actually took, naming each system touched: querying Zendesk for matching open tickets, pulling account history from Salesforce, identifying the root cause, drafting the resolution email, then closing with the ticket resolved and a CSAT survey triggered.

The governance layer states every worker operates with identity, permissions and full auditability, a named runtime component adds auditing built into every action, and the vendor publishes a separate piece on audit-grade workflow logging. Per-worker operating metrics report tasks in twenty-four hours, resolution rate and average cost per task.

Sourcejeeva.ai worker runtime, governance layer and worker walkthrough sectionsread 2026-09-01

Memory is one of five named architecture layers and the vendor states two tiers with different lifetimes: session history for session state and persistent memory for durable knowledge, described as what separates workers from workflows. Shared Memory is a named runtime component, with workers retaining context across tasks, conversations and systems, which states the scope. The retention period, and whether a customer can inspect or edit the store, are not published.

Sourcejeeva.ai five-layer architecture L4 and worker runtime sectionread 2026-09-01

The deployment and hosting page documents three models: shared multi tenant SaaS, logically isolated tenant spaces, and a dedicated single tenant VPC in a fresh AWS account with its own compute, storage and KMS keys, reachable over AWS PrivateLink. Region is a configurable choice, with the worked example of an EEA customer pinning primary storage to eu-central-1 and replicating to eu-west-1. The pricing page lists private cloud or on premises deployment on the Enterprise plan.

Sourcejeeva.ai/enterpriseready/deployment-hosting-flexibilityread 2026-09-30

Six named workers ship aimed at named jobs, each with a published multi-step process and a deploy control: Support Resolution for tier-1 and tier-2 tickets, IT Operations for access provisioning and incidents, Revenue for opportunity-stage enrichment and follow-up, GTM Engineer for campaign automation and funnel routing, Security Ops for anomaly investigation, and Finance for invoice and purchase-order matching, with a human resources onboarding worker shown alongside.

The vendor reports six workers in production and publishes operating metrics for each. New workers are created by describing them in natural language rather than assembled from parts.

Sourcejeeva.ai workers running today and deployment sectionsread 2026-09-01

The perception layer of the published architecture names the trigger set directly: intent classification on inbound signals, from webhooks, tickets, alerts and schedules.

The revenue worker is documented as operating on opportunity stage changes and acting at every signal, and Continuous Execution is a named runtime component with workers monitoring and responding around the clock.

Reach is into the systems people already work in rather than a console of its own, with workers operating across CRM, email, support, identity and business systems, sending from connected mailboxes, resolving tickets in the helpdesk and booking to calendars.

Sourcejeeva.ai architecture layer L1 and worker runtime sectionsread 2026-09-01

No customer-facing model choice is documented. The five-layer architecture names perception, cognition, action, memory and governance without naming a model, no published page discloses which models power the workers, and no model selector, per-worker choice, bring-your-own-key or routing policy appears anywhere.

Sourcejeeva.ai architecture, worker pages and site navigationread 2026-09-01

Inbound webhooks are documented as one of the signal types the perception layer accepts, alongside tickets, alerts and schedules, which is a surface a customer's own systems can call. No API reference, SDK or MCP server is published, and the builder platform is a no-code surface rather than a programmatic one.

Sourcejeeva.ai architecture layer L1, site navigation and footerread 2026-09-01

The GTM Engineer worker is documented as running A/B routing across the funnel, and the cognition layer states workers self-heal, which is runtime recovery rather than a test the customer runs. Nothing lets a buyer evaluate a change before it reaches customers; no evaluation harness, scored test cases, preview or dry run of a worker against held-out data, or comparison between worker versions is documented.

Sourcejeeva.ai worker descriptions and architecture layer L2read 2026-09-01

The action layer states API connectors plus browser automation, making real changes in real systems, and a LinkedIn worker sends connection requests and tracks accepts and replies, so the vendor documents its agents acting on interfaces it does not control. The mechanism is not stated; browser automation is named in a two-word architecture label, with nothing describing whether the browser is hosted by the platform, run locally, or supplied by a third-party engine.

Sourcejeeva.ai architecture layer L3read 2026-09-01