DECENTRA × RECTANGLEAGENTIC USE-CASE JOURNEYS
Shared foundation / Existing execution environment

What every workflow needs.

Different business tasks. The same controlled execution pattern.

Each job starts with one represented organization, prepared data and only the capabilities it needs. The agent works within that scope; permitted actions are controlled and their outcomes verified.

Decentra’s execution environment already operates at scale. The work with Rectangle is to connect its selected systems and configure each workflow within the represented organization’s authority.

The workflow behind every workflow

From a business event
to a verified outcome.

  1. 01
    Trigger & scope

    Identify the job.

    A receipt arrives, an invoice needs follow-up or an approved payable is ready. Spawn a fresh session for the appropriate agent, scoped to the practice in question—or the seller or payer/TPA for that workflow—with a defined task and the authority already granted by that organization.

    One organization. One defined task. A clear permission boundary.

  2. 02
    Prepare & isolate

    Prepare an isolated session.

    Trusted services gather the permitted records, classify their sensitivity, minimize or redact fields where appropriate, and validate their source and task scope before releasing them to the session.

    Start fresh with this prepared context and only the approved skills, rules and integration capabilities needed for the job—not another customer’s history or a broad catalog of tools.

    ClassifyMinimize / tokenizeValidate source & scopeRelease permitted context

    Isolation is enforced by the environment. Credentials stay in controlled services, not model context; model access follows the approved data-disclosure policy. Redaction alone is not proof of de-identification.

    A task-specific session with bounded data and capabilities.

  3. 03
    Investigate & resolve

    Work through the task.

    The agent examines the evidence, checks what existing automation has already completed and works through unresolved items. It uses permitted capabilities to request missing information through controlled integrations—not unrestricted access to customer systems.

    Supported findings, a proposed action or a specific missing-information request.

  4. 04
    Authority & controlled execution

    Apply the permitted action.

    DecentraCore checks the relevant operation against current authority and policy. Controlled services validate the proposed change against current records and execute it through the approved integration.

    Within standing authority

    Proceed without a fresh human approval for every routine step.

    Outside authority or unresolved

    Hold the action and route it to the appropriate decision-maker or exception queue.

    Only the necessary, supported and permitted action proceeds.

  5. 05
    Verify & retain

    Verify, retain and close.

    Read back the actual result from the authoritative systems. Keep payment submission, settlement, remittance delivery and accounting posting distinct. Retain the evidence, verified outcome and any outstanding work, then end the session.

    An unknown payment or write outcome requires inspection and recovery before retrying. An agent’s success message is not proof that the business result occurred.

    Verified completion—or an explicit open item with an owner and next action.

Temporary session / durable work

The session ends. The work does not disappear.

If a document, decision or payment update takes days to arrive, the task waits outside the runtime. The response triggers a fresh session with updated, validated context and current authority—not a permanently running bot.

The session is temporary. The organization’s boundaries remain enforced. The work and its evidence persist.

Custody is not authority

Clear roles around every job.

Rectangle

The proposed custodian and operator of the agent service. Deploying and operating it does not itself grant authority over every customer’s records or actions.

Represented organization

The practice, seller or payer/TPA defines what may be done on its behalf. Each organization’s data, credentials and permissions remain scoped to it.

Agent runtime

Runs the isolated, task-specific session: examines evidence, coordinates permitted work and produces findings or proposed actions.

DecentraCore

Governs relevant operations through identity, standing authority, policy, controlled execution and evidence. It is distinct from the agent runtime and the business systems of record.

Connected systems

Supply source evidence, perform supported operations and hold the authoritative records used to verify the result.

Same foundation / different jobs

The workflow changes.
The operating pattern stays.

Insurance receipts

The practice’s agent connects an incoming receipt to its explanation and records. It verifies permitted posting; it does not initiate another insurer payment.

Business receivables

The seller’s agent investigates an unpaid business invoice and verifies receipts and balances. Seller authority never substitutes for buyer payment authorization.

Insurer payments

The payer/TPA’s agent handles already-approved payables. Rectangle’s outbound role and the qualified disbursement partner are agreed for that relationship; the agent does not re-adjudicate claims.

Where it lives / How it connects

Deployed within Rectangle.
Built around each practice’s work.

DecentraCore deploys within Rectangle, connects to its systems and responds to business triggers. It gathers and checks the required data, then spawns the appropriate agent’s secure session for the practice in question—with scoped capabilities, authority checks and an attributable audit trail.

DecentraCore deployed within RectangleInside Rectangle’s environment, DecentraCore receives business triggers, retrieves data through Rectangle’s systems and connected interfaces, checks practice scope and authority, and prepares the task. It spawns the appropriate agent’s secure, practice-specific session through the runtime. The session returns results and action requests for controlled execution and verification. Checks and an attributable audit trail span the lifecycle. This illustrates the deployment and integration model, not completed Rectangle integration. RECTANGLE ENVIRONMENTDecentraCore is deployed here—not as a replacement for Rectangle’s systems. Business triggersReceipt arrives · invoice agesAuthorized request or update Rectangle systemsPayerSync · payments · reportingConnected practice / ISV recordsScoped reads, actions and read-back Practice-granted authorityPermitted records and actionsLimits · approvals · revocationPractice decides; Rectangle operates DecentraCoreCoordinates the job and governs its operations 1 / Receive and scope the triggerBind the job to the right practice and authority.2 / Gather and check the dataRetrieve permitted records through integrations.Classify, minimize and validate task context.3 / Prepare the appropriate agent’s sessionSelect only the skills and capabilities for this job.Check authority and data before execution. Spawn via the agent runtime Secure session · this practice · this taskPrepared context · narrow tools · enforced isolationReturns findings and action requests to CoreTemporary runtime; no other practice’s context or credentials Core checks permitted actions and verifies outcomes through the connected systems. Checks, balances and audit trail across the lifecycleAuthority · input checks · controlled actions · verified results · durable task history Practice-side example. For seller or payer / TPA workflows, the represented organization and permitted systems change.
Deployment and integration view for Rectangle, illustrated with a practice-side task. Decentra’s execution environment exists at scale; the specific Rectangle connectors and operating configuration are agreed together. Arrows show triggers, data and governed requests—not funds movement. On narrow screens, scroll horizontally.
Download diagram as SVG ↓

The session works; Core governs. Routine actions within standing authority proceed without repeated approval. Exceptions go to the appropriate owner, results are verified against the connected systems, and task state and evidence persist after the session ends. The agent runtime remains distinct from Core; credentials stay in controlled services, not model context.