Framework

The framework boundary between agent programs and external generative resources.

Core concepts

Agent Layer

The host agent platform and its execution semantics.

  • Autonomous Control: Deliberates over active goals and plans, acting as the final arbiter that evaluates generated suggestions before any host-side materialisation.
  • Asynchronous Triggers: Inquires external support asynchronously, maintaining internal stability while waiting for generative responses.
  • Context-Guarded Decision: Employs native agent guard conditions to decide whether to adopt, verify, ignore, or reject the candidate material.

Adapter

The bridge between an agent framework and Generative Layers.

  • Datatype Translation: Maps native agent datatypes, such as AgentSpeak terms, structures, and lists, to standard Java parameters and vice versa.
  • Syntactic Integration: The translation layer bridging agent execution environments with the Generative Layers kernel.
  • Governed Lifecycle Binding: Isolates provider bindings per agent while sharing underlying stores, enabling cross-agent candidate evaluation and lifecycle ID resolution.

Governance Boundary

Policy, limits, audit, and admissibility checks.

  • Decoupled Safety Policies: Out-of-band enforcement of budgets, rate limits, and content policies, shielding the host agent’s reasoning state from raw LLM interactions.
  • Assessment & Admissibility Gating: Gates candidate acceptance through an evidence-based pipeline, where peer judgments (judge()) feed into an admissibility checker (decide()).
  • Audit Logging & Tracing: Automatically generates globally unique trace IDs to log request contexts, checked policies, and outbound results.
  • Pre-Adoption Verification: Intercepts responses, validating schemas and active rules before exposing candidate material to the agent.

Provider

The abstract connector to an LLM endpoint.

  • Resource Abstraction: Standardizes LLM provider interfaces into a uniform, swappable execution target.
  • Resilience & Networking: Encapsulates HTTP requests and provider-specific retry handling behind the provider abstraction.
  • Unified Interface: Simplifies provider switching, such as swapping model endpoints or mock providers, with zero changes to agent logic.

Candidate Material

External output that may be adopted, verified, ignored, or rejected.

  • Isolated Sandbox: Quarantines raw LLM outputs as candidate material (cand_), tracking them through lifecycle statuses such as VALIDATED, INVALID, ASSESSED, ACCEPTED_BY_AGENT, and REJECTED_BY_AGENT.
  • Structured Inspections: Provides safe query boundaries through check() and get() so agents can inspect data before adoption.
  • Deliberated Incorporation: Candidate fields become GL-side knowledge only when the agent explicitly adopts the candidate through accept(candidateId, reason); host belief insertion remains a separate explicit agent-program step.

Governance Modularity

Modular design vectors and parameter overrides for developers and researchers.

  • Model & Provider Swapping: Easily swap model sizes (e.g. 8B vs 70B) or API providers to benchmark latency, accuracy, and cost.
  • Structural Schemas: Tailor the exact CSV schema fields required for syntactic validation.
  • Context Grounding: Inject pre-state agent beliefs directly into LLM prompt environments.
  • Categorical & Numeric Gating: Define qualitative tiers (high, medium, low) or numeric limits (score ≥ 0.85) to control acceptance.
  • Consensus Dynamics: Modify quorum rules (majority vs. unanimity) in multi-agent environments.

Request path

1. see() discovers available providers. bind() establishes a secure transaction context between agent and provider.
Discovery & Binding
↓
2. call() starts an out-of-band transaction: policy checks → query dispatch → syntax validation → sandboxed candidate creation.
Invocation
↓
3. candidate() resolves the candidate ID. check() and get() allow read-only inspection of candidate status and fields.
Inspection
↓
4. judge() records evaluative evidence. decide() previews admissibility from candidate status and assessments.
Assessment
↓
5. accept() records final adoption; reject() records final non-adoption. Host belief insertion remains separate and explicit.
Decision
↓
6. knowledge() retrieves accepted GL-side candidate fields; explain() audits lifecycle records and traces.
Knowledge & Audit

Canonical commands

The framework establishes a canonical contract of 13 lifecycle commands exposed across target platforms. Platform adapters preserve the same lifecycle semantics, while syntax and return-value style may differ.

Lifecycle diagram

Interactive view of the complete GL v2 governed lifecycle — all 13 commands, 7 candidate statuses, the 5-stage invocation pipeline, retry/recovery, belief-context grounding, conversation context, admissibility rules, finality guards, and the host-agent belief boundary. Scroll to zoom, drag to pan.

GL v2 Complete Lifecycle Diagram