Generative Layers

How it Works

Generative Layers provides a governed resource boundary between agent programs and external generative capabilities.

Basic execution model

An agent does not hand over its reasoning cycle to an LLM. Instead, the agent makes a controlled request through a platform adapter. The framework checks the request, invokes the selected provider, records the interaction, and returns a structured result.

  1. Agent request: an ASTRA or Jason program asks for generative support.
  2. Adapter translation: the platform-specific adapter converts the request into the shared Generative Layers request model.
  3. Governance check: policies and admissibility constraints decide whether the request is allowed.
  4. Provider call: the selected provider invokes an LLM, API, tool, service, or resource module.
  5. Result normalisation: the response becomes a structured result with status, metadata, warnings, and audit information.
  6. Agent adoption: the agent decides whether to use, ignore, verify, store, or act on the returned material.

How each platform fits

Jason

Jason is the first academic reference target. A Jason adapter should expose Generative Layers as internal actions or environment-level services. The key test is whether generated outputs can be kept outside the belief base until the agent deliberately adopts them.

ASTRA

ASTRA is the first practical implementation target. A Generative Layers integration can be explored through modules, actions, sensors, predicates, and events. This makes ASTRA suitable for fast experiments on governed LLM calls and structured resource responses.

JaCaMo

JaCaMo is relevant when the research expands from single-agent calls to multi-agent settings involving agents, artifacts, and organisations. Generative Layers can be used to study whether governance should sit at the agent, environment, or organisation boundary.

CArtAgO

CArtAgO is relevant for modelling tools and external services as artifacts. This is useful when generative capabilities should appear as shared environmental resources rather than as hidden internal agent functions.

What the framework should not do

It should not automatically turn generated text into beliefs. It should not silently execute generated tool calls. It should not hide failures, policy denials, or unsafe outputs. It should not replace the semantics of the host agent language.

Example use cases

Prompted assessment

An agent asks an LLM to assess a situation, but the output is returned as an assessment object rather than directly changing beliefs.

Candidate plan generation

A provider proposes candidate plan steps. The BDI agent checks whether the proposal is admissible before adopting or executing anything.

Tool/resource mediation

The framework controls when a tool or API may be called, with audit records and policy checks around the interaction.

Cross-platform experiments

The same resource-layer idea can be tested in ASTRA and Jason to compare behaviour across agent programming platforms.

Research value

The framework creates a concrete implementation space for studying how modern agentic AI techniques can be integrated into agent-oriented programming without destroying the separation between reasoning, governance, and external resource use.