Agent Execution and Orchestration

Telynt executes installed AgentPackage definitions over authorized typed inputs. Its runtime provides bounded execution, durable orchestration, model and tool gateways, isolation, provenance, review controls and operational audit. It does not hard-code business agents into the kernel.

Contract ownership

The contracts below describe what every admitted package must satisfy. Domain-specific examples illustrate a possible installed package; they do not make meeting, finding, project or coaching models mandatory. Business memory schemas and personal recommendation history are owned by their packages and remain subject to common memory and authorization controls. ASR, diarization and OCR are optional model/tool capabilities, not additional agents or universal kernel requirements.

Platform Architecture

Sources and business systems
            |
            v
Ingestion, media, ASR, diarization, document and index services
            |
            v
Policy engine and permission-aware evidence layer
            |
            v
Context Assembly + Entity and Object Resolution
            |
            v
Agent Orchestrator ---- Model Router ---- Inference Gateway
      |                       |                   |
      |                       +---- Model registry
      |                            Effority + customer packages
      |
      +---- Specialized native and customer agents
      |       execution, commercial, relationship, ethics,
      |       engineering, coordination, recommendations,
      |       search, reports and operations
      |
      v
Evidence Verification + Finding Reconciliation + Confidence Calibration
            |
            v
Human Review, Cases, Approval Workflows and External Drafts
            |
            v
Product UI, API, reports, notifications and approved synchronizations

Cross-cutting:
identity, RBAC/ABAC, tenant isolation, secrets, audit, retention,
evaluation, observability, quotas, cost controls and kill switches

Implemented Protocol Responsibility Model

Telynt uses a protocol-centered architecture with one owner for each responsibility:

MCP does not perform agent delegation; A2A does not replace internal typed handoffs; AG-UI does not store durable state; CloudEvents does not grant delivery or authorization guarantees; framework checkpoints do not supersede Temporal. These boundaries prevent duplicate orchestration, memory, policy, and audit systems.

Framework-Neutral Agent Authoring

The native SDK is the default authoring surface. Qualified adapters support OpenAI Agents SDK, Google Agent Development Kit, Microsoft Agent Framework, and LangGraph. A language-neutral gRPC, HTTP, MCP, or A2A contract adapter accepts other customer-selected frameworks after package conformance and evaluation. Each adapter translates framework-native sessions, tools, handoffs, events, checkpoints, and results into canonical Telynt contracts. Semantic Kernel and AutoGen are supported as migration inputs into Microsoft Agent Framework or the native contract.

Frameworks remain inside isolated workers. They receive no direct database credentials, durable-authority role, unrestricted tool surface, or separate policy model. Exact qualified versions and adapter limitations are recorded in the technology baseline and each AgentPackage compatibility record.

Runtime Planes

Control Plane

The control plane contains:

• agent-orchestrator for Temporal-backed durable workflow execution;
• agent-registry for agent manifests, versions, ownership, and deployment state;
• model-registry for model artifacts and compatibility;
• artifact-registry for signed OCI artifacts, attestations, bills of materials, and immutable digests;
• identity-control-plane for SPIRE attestation and SPIFFE workload identity;
• policy-engine for OpenFGA relationships and OPA/Rego eligibility, ABAC, purpose, and action decisions;
• protocol-registry for qualified MCP servers, A2A agents, AG-UI subsets, and framework adapters;
• trigger-service for event, schedule, API, and user triggers;
• deployment-controller for shadow, canary, production, suspension, and rollback;
• configuration-service for tenant scopes, budgets, thresholds, and feature activation.

The control plane stores metadata and execution state. It does not expose literal conversation content to administrators who lack content authorization.

Evidence and Context Plane

The context plane exposes permission-aware retrieval over package-registered resource types, their versions, provenance, temporal relationships and authorization metadata. Lexical, semantic and graph retrieval are shared services; packages define indexed entities and permitted uses.

For example, the Evidence, Meeting and Findings packages register transcripts, documents, source locators and reviewed findings. These schemas are package contributions, not mandatory platform master data.

Every retrieval request includes tenant, user or service principal, purpose, policy decision, object scope, time range, language, and sensitivity ceiling.

Execution Plane

The execution plane contains:

• isolated agent workers;
• framework-neutral native and qualified framework-adapter workers;
• model routing;
• inference adapters;
• policy-wrapped MCP and tool gateway;
• A2A gateway for independently deployed agents;
• gVisor, Wasmtime/WASI, and high-assurance microVM runner profiles;
• schema validators;
• bounded run state;
• ephemeral context and scratch data;
• GPU and CPU resource pools.

Workers receive short-lived credentials scoped to one invocation. They have no default network access and no direct write path to source systems.

Assurance Plane

The assurance plane performs:

• schema validation;
• citation existence and checksum validation;
• field-level evidence entailment;
• permission revalidation;
• confidence calibration;
• duplicate and contradiction detection;
• policy and recipient checks;
• human-review routing;
• output redaction and minimization.

A material finding is not published until its applicable assurance gates pass.

Operations Plane

The operations plane provides:

• OpenTelemetry/OTLP traces, metrics, and logs using the pinned Telynt GenAI semantic profile;
• run, step, model, tool, and validation logs;
• queue, latency, throughput, token, GPU, and cost dashboards;
• model and agent quality dashboards;
• drift and human-rejection monitoring;
• evaluation-gate results;
• canary comparisons;
• rollback, pause, and kill-switch controls;
• tenant-visible audit and package ownership views.

Literal source content is excluded from ordinary technical logs.

Package Model

Package Envelope

Every distributable extension uses a signed package envelope. The package model includes DataModelPackage, WorkflowPackage, ModelPackage, AgentPackage, ToolPackage, ConnectorPackage, PolicyPackage, InterfacePackage, EvaluationPackage, and the non-executable ConfigurationBundle composition artifact. Executable payloads additionally use the ExtensionPackage runtime profile appropriate to their isolation class.

The envelope is an immutable OCI 1.1 artifact verified by cosign and linked to in-toto/SLSA provenance, an SPDX 3 bill of materials, vulnerability and license results, evaluation attestations, and a compatibility matrix. An AgentPackage references one or more compatible ModelPackage versions. A WorkflowPackage references capabilities supplied by agents, tools, models, policies, and data models. Updating any package, authoring adapter, protocol gateway, policy, or runtime does not silently update a deployment.

The composition rules, bundle relationships, data-model lifecycle, interface and navigation extension points, contextual Marketplace, and compatibility resolver are defined in the Composable Package, Customization, and Marketplace Architecture.

AgentPackage Manifest

{
  "schema_version": "agent-package.v2",
  "agent_id": "effority.project-execution",
  "version": "2.4.1",
  "origin": "EFFORITY",
  "owner_tenant_id": null,
  "artifact": {
    "oci_ref": "registry.internal/agents/project-execution@sha256:...",
    "signature": "cosign:verified",
    "provenance": "slsa-v1.2-build-l3",
    "sbom": "spdx-3"
  },
  "authoring": {
    "adapter": "telynt-native",
    "adapter_version": "1.0.0",
    "agent_contract": "telynt-agent.v1"
  },
  "protocols": {
    "tools_and_context": "mcp-2026-07-28",
    "remote_agent": null,
    "ui_events": null
  },
  "sandbox_profile": "container-restricted",
  "purpose": "Detect evidence-backed project execution changes",
  "triggers": [
    "transcript.published",
    "document.version_created",
    "finding.reviewed"
  ],
  "input_schemas": [
    "agent-invocation.v1",
    "context-package.v2"
  ],
  "output_schemas": [
    "agent-result.v1",
    "finding.v3"
  ],
  "model_routes": [
    "extract-fast",
    "analyze-balanced",
    "reason-deep"
  ],
  "tools": [
    "evidence.search",
    "graph.read",
    "document.clause_read",
    "finding.read"
  ],
  "max_steps": 8,
  "max_tool_calls": 16,
  "timeout_ms": 180000,
  "context_budget": {
    "max_sources": 40,
    "max_tokens": 64000
  },
  "review_policy_id": "material-project-finding.v2",
  "evaluation_suite_id": "project-execution-gates.v4",
  "network_policy": "deny-all",
  "retention_profile": "agent-run-standard",
  "termination_conditions": [
    "result_validated",
    "insufficient_evidence",
    "budget_exhausted",
    "policy_revoked"
  ]
}

Manifest Validation

Registration verifies:

• globally unique agent ID and semantic version;
• immutable OCI digest, Effority or customer-tenant cosign signature, and registry trust domain;
• in-toto/SLSA provenance and SPDX bill of materials;
• ownership and distribution scope;
• authoring-adapter and canonical agent-contract compatibility;
• MCP, A2A, AG-UI, CloudEvents, OpenAPI, and schema conformance for every declared boundary;
• selected container, gVisor, Wasmtime/WASI, Kata/Firecracker, or confidential-workload isolation profile;
• supported schemas and compatibility range;
• permitted model and tool dependencies;
• resource and execution budgets;
• declared network, file, and secret access;
• evaluation suite and quality thresholds;
• privacy, retention, and logging behavior;
• review, escalation, and external-write rules.

A package with an incomplete or incompatible manifest remains quarantined.

Agent Execution Contract

Invocation

Every run starts from a versioned invocation:

{
  "schema_version": "agent-invocation.v1",
  "invocation_id": "ainv_01...",
  "agent_deployment_id": "adep_01...",
  "tenant_id": "tnt_01...",
  "trigger": {
    "type": "EVENT",
    "name": "transcript.published",
    "event_id": "evt_01..."
  },
  "actor": {
    "type": "SERVICE",
    "id": "svc_agent_orchestrator"
  },
  "purpose": "PROJECT_EXECUTION_ANALYSIS",
  "policy_decision_id": "pol_01...",
  "subject_refs": [
    "meeting:mtg_01...",
    "project:prj_01..."
  ],
  "source_versions": [
    "transcript:trv_07...",
    "document:sow_03..."
  ],
  "locale": "en-US",
  "deadline_at": "2025-05-16T10:35:00Z",
  "idempotency_key": "sha256:..."
}

The orchestrator rejects an invocation without a current policy decision, authorized subject scope, pinned agent deployment, or idempotency key.

Context Package

The Context Assembly Agent produces context-package.v2 with:

• authorized source references and version IDs;
• selected transcript windows and document chunks;
• business-object graph slice;
• relevant current and historical findings;
• taxonomies and role playbooks;
• source authority and validity metadata;
• ACL, sensitivity, and allowed-recipient markers;
• remaining context budget;
• explicit exclusions and unavailable sources.

The package records restricted sources as excluded counts without revealing their identity or existence to an unauthorized recipient.

Result

{
  "schema_version": "agent-result.v1",
  "agent_run_id": "arun_01...",
  "agent_id": "effority.project-execution",
  "agent_version": "2.4.1",
  "status": "COMPLETED",
  "subject_refs": [
    "project:prj_01..."
  ],
  "artifacts": [
    {
      "type": "FINDING",
      "schema_version": "finding.v3",
      "artifact_id": "fnd_01..."
    }
  ],
  "evidence_refs": [
    {
      "source_ref": "utterance:utt_381",
      "start_ms": 2841200,
      "end_ms": 2857300,
      "content_hash": "sha256:..."
    }
  ],
  "confidence": 0.91,
  "validation": {
    "schema": "PASSED",
    "citations": "PASSED",
    "entailment": "PASSED",
    "permissions": "PASSED",
    "policy": "PASSED"
  },
  "review_disposition": "HUMAN_REVIEW_REQUIRED",
  "model_run_refs": [
    "mrun_01..."
  ],
  "completed_at": "2025-05-16T10:33:41Z"
}

Supported terminal statuses are:

• COMPLETED;
• ABSTAINED;
• NEEDS_REVIEW;
• BLOCKED;
• CANCELLED;
• EXPIRED;
• FAILED_RETRYABLE;
• FAILED_PERMANENT.

ABSTAINED is a successful outcome when authorized evidence does not support a result.

Run State Machine

RECEIVED
  -> POLICY_CHECKED
  -> CONTEXT_ASSEMBLED
  -> QUEUED
  -> RUNNING
  -> VALIDATING
  -> RECONCILING
  -> REVIEW_ROUTED
  -> COMPLETED

Terminal alternatives:
ABSTAINED, BLOCKED, CANCELLED, EXPIRED, FAILED_PERMANENT

Recoverable alternatives:
WAITING_FOR_TOOL, WAITING_FOR_DEPENDENCY, RETRY_SCHEDULED,
NEEDS_REVIEW, DEGRADED

Every transition persists:

• previous and new state;
• timestamp and lease owner;
• input and output hashes;
• agent, model, prompt, tool, schema, and policy versions;
• resource usage and latency;
• error or review reason;
• trace, correlation, and audit references.

Trigger and Scheduling Model

Agents execute from:

• domain events;
• explicit user actions;
• approved API requests;
• periodic schedules;
• source corrections and invalidations;
• human-review outcomes;
• threshold or anomaly events;
• administrator-controlled reprocessing.

The trigger service resolves tenant feature activation, agent deployment, policy, priority, and dependency graph before creating a run.

Priority classes are:

1. SAFETY_CRITICAL;
2. INTERACTIVE;
3. REALTIME;
4. POST_MEETING;
5. BACKGROUND;
6. EVALUATION.

The scheduler enforces separate queues and concurrency limits per tenant, agent, model route, and hardware pool.

Orchestration Patterns

Fan-Out and Fan-In

After a canonical transcript and context package exist, independent domain agents execute in parallel. The assurance agents then validate and reconcile their outputs before publication.

Typed Handoff

One agent hands work to another only through a declared schema. A handoff contains the parent run, purpose, artifact references, policy decision, remaining budget, and permitted recipient agent IDs.

Supervisor and Worker

The orchestrator, not a generative supervisor, owns workflow state. A bounded coordinator agent appears only when a task requires dynamic selection among an allowlisted set of workers. The orchestrator validates every selection.

Independent Verification

The agent that creates a material finding never performs the final evidence-verification decision for that finding. The Evidence Verification Agent uses an independent prompt or model route and receives the candidate output plus authorized evidence.

Conflict Preservation

The reconciliation process:

1. groups artifacts by type, subject, time, and evidence;
2. merges exact or semantically equivalent duplicates;
3. preserves differing source statements as explicit contradictions;
4. links updates to prior findings;
5. applies human-confirmed state over unreviewed suggestions;
6. retains source and model provenance for every variant;
7. routes unresolved material conflicts to review.

The platform does not manufacture consensus by majority vote among agents.

Tool Contract

Agents invoke tools only through tool-gateway. Every tool declares:

• tool ID and version;
• read or write risk class;
• JSON input and output schemas;
• required permissions and purposes;
• supported object types;
• rate and resource limits;
• timeout and retry behavior;
• audit fields;
• data-retention behavior.

Tool calls include the current tenant, policy decision, subject scope, agent run, and idempotency key. The gateway rechecks authorization for every call.

MCP is the external and extension-facing tool/context protocol. Native tools and MCP servers converge on the same canonical contract, deterministic authorization, trust-label propagation, schema validation, resource limits, and audit path. MCP metadata and content are untrusted data; an MCP server never grants permissions or changes agent instructions.

Tool Risk Classes

No agent receives an unrestricted SQL, shell, file-system, credential, browser, or network tool.

Memory Model

Telynt does not maintain hidden, unbounded personal memory inside agents.

Source Memory

Registered source artifacts and their authorized derivatives retain immutable version references and provenance. Retention and deletion follow the owning package's policy and platform controls.

Business Memory

Package-defined entities and relationships use a temporal, provenance-aware memory contract. The platform does not impose a universal project, finding or decision schema.

Run Memory

Each agent run retains bounded structured state, tool results, decision traces, and hashes according to the configured run-retention profile. Ephemeral prompt context is deleted after the authorized period.

Review Memory

Human confirmations, modifications, rejections, and reasons remain versioned feedback. Review data enters model training only through a separately authorized curated dataset.

Purpose-Separated Memory

Packages declare the audience, purpose, retention and access policy for each memory scope. The runtime prevents cross-purpose reuse without explicit authorization. For the private coaching implementation, see Personal Development.

Model Routing

The model router selects a registered deployment using:

• tenant and package ownership;
• task and agent compatibility;
• language and domain;
• source sensitivity;
• latency class;
• context length;
• hardware availability;
• evaluation status;
• canary allocation;
• customer override;
• cost and resource budget.

There is no implicit fallback to a public model. An external model route exists only under an explicit tenant policy and compatible source classification.

Security and Isolation

The platform enforces:

• tenant ID in every key, event, trace, index, invocation, and artifact;
• SPIFFE/SPIRE workload identity and mTLS with short-lived X.509-SVIDs;
• OpenFGA object-relationship and task-bound authorization;
• OPA/Rego contextual policy and action enforcement;
• short-lived scoped tokens for tools and evidence;
• separate encryption domains for customer packages;
• deny-by-default network and file-system policies;
• container or sandbox isolation for custom execution;
• image signature and vulnerability verification;
• OCI artifact digests, cosign signatures, in-toto/SLSA provenance, and SPDX bills of materials;
• prompt-injection isolation between instructions and source content;
• provenance, sensitivity, and trust-label propagation through context, tools, handoffs, and memory;
• secret-free prompts and logs;
• pre-retrieval ACL filtering;
• output permission and recipient validation;
• content minimization and tokenization;
• immutable audit for runs, tools, reviews, deployments, and writes;
• kill switch by tenant, agent, model, purpose, and source.

A source document is always untrusted data. Text inside a meeting, email, document, or webpage never changes an agent's system instructions, tools, policies, or execution budget.

All model outputs, agent plans, framework handoffs, and tool arguments are untrusted proposals. Only the deterministic policy enforcement point grants an action after correlating user, workload, agent, task, tenant, object relationship, policy, data provenance, risk, and approval. Authority is never inferred from natural language.

Human Review and Authority

The Review Routing Agent derives the required workflow from:

• finding type;
• severity and calibrated confidence;
• source quality;
• affected people and objects;
• recipient and intended use;
• ethics, employment, contractual, financial, or external-write impact;
• tenant policy;
• restricted-source involvement.

Human review outcomes are CONFIRMED, MODIFIED, REJECTED, WITHDRAWN, or ESCALATED. The result records reviewer, authority, reason, timestamp, source version, and policy.

The platform never allows an agent to:

• impose an employment sanction;
• open a formal ethics investigation without the defined human decision;
• treat a possible contractual acceptance as legally established;
• publish a customer communication without approval;
• update CRM, project, ticketing, or document systems outside the approved-write workflow;
• infer protected attributes, personality, mental health, emotion as fact, sincerity, or criminal intent.

Reliability and Scaling

The Temporal-backed orchestrator provides:

• durable workflow state;
• at-least-once Activity execution semantics with idempotent effects;
• expiring worker leases;
• bounded retries with exponential backoff and jitter;
• terminal workflow-failure queues with diagnostic context and operator recovery;
• checkpoint recovery;
• cancellation and policy-revocation propagation;
• tenant and workload backpressure;
• horizontal agent-worker scaling;
• separate real-time and batch capacity;
• graceful degradation to transcript-only operation;
• replay from pinned source and package versions.

The Kafka-compatible broker, not Temporal, owns at-least-once delivery, consumer retry, ordering guarantees, and dead-letter queues for internal CloudEvents. Event consumers remain idempotent. Temporal owns workflow and Activity state, retries, timers, cancellation, compensation, and replay; a broker delivery never becomes workflow authority.

The default retry classes are:

Evaluation and Qualification

Every agent version passes:

• package integrity and dependency checks;
• input and output schema conformance;
• purpose and tool-boundary tests;
• permission and cross-tenant leakage tests;
• citation existence and entailment tests;
• unsupported-claim and abstention tests;
• task-specific precision, recall, F1, and calibration;
• difficult-negative and ambiguity tests;
• prompt-injection and exfiltration tests;
• harmful-output and prohibited-inference tests;
• latency, throughput, memory, token, and GPU tests;
• cancellation, retry, idempotency, and rollback tests;
• human-review workflow tests;
• language and domain segment tests.

The four isolated deployment nodes are:

DEVELOPMENT -> TESTING -> STAGING -> PRODUCTION

Lifecycle states operate inside those nodes rather than acting as additional environments. Development contains authoring and build states. Testing runs automated evaluation and qualification. Staging performs production-equivalent deployment, migration, rollback, and shadow validation. Production begins with the configured canary state before a release becomes fully active.

Hard gates block promotion. Shadow results remain invisible to end users. Canary runs compare quality, latency, cost, error rate, abstention, and human-review outcomes against the active baseline. The deployment controller promotes the same signed artifact digest between nodes and never rebuilds an already qualified version.

Every modification has a versioned ChangeSet that links its source revision, affected packages and features, field-level and artifact-level diff, evaluation evidence, approvals, environment-lock transition, and rollback target. Git-compatible source control, immutable OCI packages, configuration and schema registries, and environment lock files form one integrated version chain. Rollback restores a previously approved lock and is itself recorded as a new immutable audit event.

Observability and Audit

Every run propagates W3C Trace Context and the following Telynt identifiers through the pinned OpenTelemetry GenAI compatibility profile:

• trace_id;
• correlation_id;
• invocation_id;
• agent_run_id;
• tenant_id;
• policy_decision_id;
• agent_deployment_id;
• model-run references;
• source-version references;
• tool-call references;
• review and artifact references.

Operational telemetry excludes literal evidence. Authorized audit views resolve evidence separately after a new permission check.

Platform APIs

Implemented platform operations are described by OpenAPI 3.2.0 and include:

• POST /v1/agent-packages;
• GET /v1/agent-packages/{id};
• POST /v1/agent-packages/{id}/evaluations;
• POST /v1/agent-deployments;
• POST /v1/agent-deployments/{id}/promote;
• POST /v1/agent-deployments/{id}/suspend;
• POST /v1/agent-deployments/{id}/rollback;
• POST /v1/agent-invocations;
• GET /v1/agent-runs/{id};
• POST /v1/agent-runs/{id}/cancel;
• GET /v1/agent-runs/{id}/artifacts;
• GET /v1/agents;
• GET /v1/tools;
• POST /v1/tools/{id}/approvals.

Every mutating endpoint uses authentication, authorization, idempotency, schema versioning, rate limits, and audit.

Platform Events

Implemented events include:

• agent_package.registered;
• agent_evaluation.completed;
• agent_deployment.created;
• agent_deployment.promoted;
• agent_deployment.suspended;
• agent_deployment.rolled_back;
• agent_run.created;
• agent_run.started;
• agent_run.completed;
• agent_run.abstained;
• agent_run.failed;
• agent_run.cancelled;
• agent_tool.approval_requested;
• agent_artifact.created;
• agent_artifact.invalidated;
• agent_review.required;
• agent_review.completed.

Every listed platform event published to the internal event backbone uses a CloudEvents 1.0.2 envelope and an AsyncAPI 3.1.0 channel contract. It carries schema version, tenant, correlation, policy decision, idempotency key, event time, producer, and audit reference. Headers contain identifiers and routing metadata; literal evidence remains in encrypted referenced objects. AG-UI, A2A, MCP, Temporal history, and synchronous RPC retain their native envelopes.

Package-owned implementations

The agent ownership index identifies the canonical package for each supplied agent. Package manuals define purpose, inputs, outputs, tools, review limits and metrics. Developers documents authoring; Platform Operations documents the operational interfaces.