Agentelic.com — Product Specification

Date: February 22, 2026 Status: v1.1 Author: [&] Ampersand Box Design License: Proprietary (open-core model)

Executive Summary

Agentelic is a premium, enterprise-grade agent builder that brings software engineering discipline to agent development. While the market is flooded with no-code agent builders optimized for demos, Agentelic targets the engineering teams that need to ship reliable agents to production — with versioned specs, deterministic testing, staged rollouts, and compliance gates.

Agentelic is the engineering layer of the [&] Ampersand Box portfolio:

SpecPrompt (Standards)    → defines agent behavior as versioned specs
    ↓
Agentelic (Engineering)   → builds, tests, deploys agents against specs  ← THIS
    ↓
OpenSentience (Runtime)   → governs, executes, observes agents locally
    ↓
Graphonomous (Memory)     → continual learning knowledge graphs
    ↓
FleetPrompt (Distribution) · Delegatic (Orchestration)

1. The Problem

According to LangChain's State of AI Agents 2026 survey, 57% of organizations now have agents in production — but 32% cite quality as the #1 barrier to scaling. Gartner predicts over 40% of agentic AI projects will be scrapped by 2027 — not because the models fail, but because organizations struggle to operationalize them. The failure isn't the AI — it's the engineering process around it.

The market in Feb 2026 is split: 20+ no-code builders (Gumloop, Lindy, Zapier) optimize for impressive first demos. Enterprise platforms like OpenAI Frontier (launched Feb 5, 2026) and Salesforce AgentForce provide governance but demand total lock-in. Neither serves engineering teams that need spec-driven design, deterministic testing, version control, compliance gates, and tool portability.

Meanwhile, only 52% of organizations run offline evaluations on test sets (LangChain survey) and 89% have implemented some form of observability — showing teams want reliability but don't have the tooling for it.

Key market data:

• AI agent builder market: $8B (2025) → $48B (2030) at 43.3% CAGR (BCC Research)

• Anthropic now captures 40% of enterprise LLM spend, up from 12% two years ago (Beam AI)

• McKinsey: Only 23% of enterprises are scaling AI agents; 39% remain stuck in experimentation

• PwC: 8 in 10 enterprises now use some form of agent-based AI

2. Design Principles

1. Spec-driven — Every agent starts from a SpecPrompt specification

2. Testable — Deterministic testing against specs, not probabilistic hope

3. Versioned — Git-native version control for agents, specs, and configs

4. Governed — Staged deployment with permission review gates

5. Observable — Full telemetry from build to production

6. Local-first — Deploys to OpenSentience, not a proprietary cloud

3. Competitive Positioning

4. Architecture

4.1 Component Stack

┌──────────────────────────────────────────────┐
│           Agentelic Studio (Web UI)           │
│   Spec editor · Test runner · Deploy console │
├──────────────────────────────────────────────┤
│              Build Pipeline                   │
│   Spec parse → Generate → Test → Package     │
├──────────────────────────────────────────────┤
│            Testing Framework                  │
│   Deterministic scenarios · Regression suites │
│   Mocked tool calls · Output validation      │
├──────────────────────────────────────────────┤
│           Deployment Engine                   │
│   Staging → Canary → Production              │
│   Permission review · Compliance gates       │
├──────────────────────────────────────────────┤
│          OpenSentience Runtime                │
│   Agent execution · Governance · Audit       │
├──────────────────────────────────────────────┤
│         Graphonomous Memory                   │
│   Continual learning · Knowledge graphs      │
└──────────────────────────────────────────────┘

4.2 Build Pipeline

SPEC.md
    │
    ▼
┌─────────────────┐
│ Spec Parser      │ Parse SpecPrompt format into
│                  │ structured requirements
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Code Generator   │ Generate agent implementation
│                  │ from parsed spec
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Test Generator   │ Generate deterministic test
│                  │ scenarios from acceptance criteria
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Test Runner      │ Execute tests with mocked
│                  │ tools and validated outputs
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Package Builder  │ Create OpenSentience-compatible
│                  │ agent manifest + bundle
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Deploy Engine    │ Stage → Canary → Production
│                  │ with permission review gates
└─────────────────┘

4.3 Deterministic Testing

defmodule Agentelic.Test do
  @moduledoc """
  Deterministic testing framework for agents.
  Tests are derived from SpecPrompt acceptance criteria.
  """

  defmacro test_spec(spec_path) do
    # Parse SPEC.md
    # Generate test cases from acceptance criteria
    # Mock all MCP tool calls
    # Validate outputs against expected behavior
    # Report pass/fail with detailed traces
  end
end

# Generated test example:
describe "customer-support-v2" do
  test "returns order status for valid order" do
    # Arrange: mock orders:read tool
    mock_tool("orders:read", %{order_id: "123"}, %{status: "shipped"})

    # Act: send query to agent
    result = Agent.handle("What's the status of order #123?")

    # Assert: output matches spec criteria
    assert result.contains?("shipped")
    assert result.tool_calls == [{"orders:read", %{order_id: "123"}}]
    refute result.contains?("internal pricing")  # constraint check
  end

  test "escalates refunds over $500 to human" do
    result = Agent.handle("I want a refund for $750")
    assert result.escalated? == true
    assert result.escalation_reason =~ "exceeds $500 limit"
  end
end

4.4 Data Model (Ecto Schemas)

4.4.1 Agents

defmodule Agentelic.Agents.Agent do
  use Ecto.Schema

  @primary_key {:id, :binary_id, autogenerate: true}

  schema "agentelic.agents" do
    field :name, :string
    field :slug, :string
    field :description, :string
    field :status, Ecto.Enum, values: [:draft, :building, :testing, :deployable, :deployed, :archived]

    # Multi-tenancy (shared Supabase ecosystem)
    belongs_to :workspace, Amp.Workspaces.Workspace, type: :binary_id  # amp.workspaces
    field :user_id, :binary_id             # amp.profiles (Supabase Auth) — agent owner

    # Spec linkage
    field :spec_path, :string              # Path to SPEC.md (relative to project root)
    field :spec_hash, :string              # SHA-256 of SPEC.md at last build
    field :ampersand_path, :string         # Path to ampersand.json
    field :ampersand_hash, :string         # SHA-256 of ampersand.json at last build

    # Build metadata
    field :framework, :string              # e.g. "elixir", "typescript", "python"
    field :runtime_target, :string         # e.g. "opensentience", "cloudflare", "agentcore"
    field :product_type, Ecto.Enum, values: [:mcp_server, :agent, :library, :website, :cli]
    field :last_build_at, :utc_datetime_usec
    field :last_test_at, :utc_datetime_usec

    has_many :builds, Agentelic.Builds.Build
    has_many :test_runs, Agentelic.Testing.TestRun
    has_many :deployments, Agentelic.Deploy.Deployment

    timestamps()
  end
end

Invariants:

• slug is globally unique, lowercase alphanumeric + hyphens

• spec_hash and ampersand_hash are recomputed on every build — stale hashes trigger a rebuild warning

• Status transitions: draft → building → testing → deployable → deployed → archived

• Only agents in deployable or deployed status can be published to FleetPrompt

4.4.2 Builds

defmodule Agentelic.Builds.Build do
  use Ecto.Schema

  @primary_key {:id, :binary_id, autogenerate: true}

  schema "builds" do
    belongs_to :agent, Agentelic.Agents.Agent, type: :binary_id
    field :version, :string                # semver from SPEC.md frontmatter
    field :status, Ecto.Enum, values: [:pending, :parsing, :generating, :compiling, :succeeded, :failed]

    # Pipeline stages (each stores timing + output)
    field :parse_result, :map              # Parsed SpecPrompt.Spec struct as map
    field :parse_duration_ms, :integer
    field :generation_result, :map         # Generated code artifacts manifest
    field :generation_duration_ms, :integer
    field :compile_result, :map            # Compilation output (warnings, errors)
    field :compile_duration_ms, :integer

    # Artifact
    field :artifact_hash, :string          # SHA-256 of build output bundle
    field :artifact_path, :string          # Storage path for the bundle
    field :error_message, :string          # Human-readable error if failed

    # Provenance
    field :spec_hash, :string              # SHA-256 of SPEC.md at build time
    field :ampersand_hash, :string         # SHA-256 of ampersand.json at build time
    field :template_version, :string       # semver of framework template used (pinned for determinism)
    field :template_hash, :string          # SHA-256 of template bundle at build time
    field :commit_hash, :string            # Git commit hash (optional)
    field :compiled_tests_hash, :string    # SHA-256 of SpecPrompt compiled tests used

    timestamps()
  end
end

Invariants:

• Builds are immutable after succeeded or failed

• artifact_hash is computed from the bundle contents — identical {spec_hash, ampersand_hash, template_hash} produce identical artifact_hash (deterministic builds)

• {agent_id, version} is unique — no duplicate version numbers per agent

• template_version must be pinned — no floating "latest" in deterministic builds

• Templates are immutable once published: new versions require new template records, never in-place updates

• {template_version, template_hash} is globally unique: same published version always has same hash

• Agent-level template pins override workspace defaults; workspace pins override global defaults (3-tier hierarchy)

4.4.3 Test Runs

defmodule Agentelic.Testing.TestRun do
  use Ecto.Schema

  @primary_key {:id, :binary_id, autogenerate: true}

  schema "agentelic.test_runs" do
    belongs_to :agent, Agentelic.Agents.Agent, type: :binary_id
    belongs_to :build, Agentelic.Builds.Build, type: :binary_id
    field :workspace_id, :binary_id             # amp.workspaces (for RLS + audit)
    field :compiled_tests_hash, :string         # SHA-256 of SpecPrompt compiled tests used
    field :status, Ecto.Enum, values: [:pending, :running, :passed, :failed, :error]

    # Results
    field :total_tests, :integer, default: 0
    field :passed_tests, :integer, default: 0
    field :failed_tests, :integer, default: 0
    field :error_tests, :integer, default: 0
    field :duration_ms, :integer

    # Individual test results
    embeds_many :results, Agentelic.Testing.TestResult
    field :coverage_summary, :map          # Which acceptance criteria were exercised

    timestamps()
  end
end

defmodule Agentelic.Testing.TestResult do
  use Ecto.Schema

  embedded_schema do
    field :test_name, :string              # Derived from acceptance test text
    field :given, :string                  # Precondition from SPEC.md
    field :expected, :string               # Expected behavior from SPEC.md
    field :actual, :string                 # Actual agent output
    field :status, Ecto.Enum, values: [:passed, :failed, :error]
    field :duration_ms, :integer
    field :tool_calls, {:array, :map}      # Recorded tool invocations
    field :assertions, {:array, :map}      # Each assertion: {type, expected, actual, passed}
    field :error_message, :string
  end
end

4.4.4 Deployments

defmodule Agentelic.Deploy.Deployment do
  use Ecto.Schema

  @primary_key {:id, :binary_id, autogenerate: true}

  schema "agentelic.deployments" do
    belongs_to :agent, Agentelic.Agents.Agent, type: :binary_id
    belongs_to :build, Agentelic.Builds.Build, type: :binary_id
    field :workspace_id, :binary_id             # amp.workspaces (for RLS)
    field :environment, Ecto.Enum, values: [:staging, :canary, :production]
    field :status, Ecto.Enum, values: [:deploying, :active, :rolled_back, :failed]

    # Target
    field :runtime_target, :string         # opensentience, cloudflare, agentcore
    field :runtime_ref, :map               # Provider-specific deployment reference

    # Governance
    field :autonomy_level, Ecto.Enum, values: [:observe, :advise, :act]
    field :delegatic_org_id, :string       # Delegatic org reference
    field :governance_policy_hash, :string # Hash of applied Delegatic policy at deploy time

    # Approval
    field :approved_by, :string            # Human approver for production deploys
    field :approval_reason, :string

    timestamps()
  end
end

Invariants:

• Production deployments MUST have approved_by set (canary and staging do not require approval)

• Only passed test runs can generate deployments

• governance_policy_hash captures the Delegatic policy at deploy time for audit reproducibility

• Rollback creates a new deployment pointing to a previous build — it does not mutate the original

• user_id on agents is audit-only (created_by at agent creation); RLS uses workspace_id, not user_id

• approved_by on deployments must be validated as a workspace admin via amp.workspace_members

4.5 API Surface (MCP Tools)

Agentelic exposes its build pipeline as MCP tools, enabling AI-assisted agent development:

4.6 Build Pipeline Specification

The build pipeline is a four-stage process. Each stage has typed input and output:

Stage 1: PARSE
  Input:  SPEC.md (raw markdown)
  Output: SpecPrompt.Spec (structured parsed spec — see SpecPrompt data model)
  Errors: Missing required sections, invalid frontmatter, malformed capability/test lines

Stage 1.5: TEST INTAKE (new — bridges SpecPrompt compiled tests)
  Input:  SpecPrompt.CompiledTest[] (from spec.compiled_tests or specprompt test-compile)
  Output: Executable test suite in Agentelic.Test.DSL format
  Rules:
    - Only approved compiled tests (approved == true) are used
    - If no compiled tests exist, fall back to LLM-assisted compilation (same as specprompt test-compile)
    - Compiled tests are cached by {spec_hash, test_index} — unchanged tests reuse prior compilations
    - compiled_tests_hash is recorded on the Build for full provenance

Stage 2: GENERATE
  Input:  SpecPrompt.Spec + ampersand.json + framework template (pinned version)
  Output: Generated source files (agent module, tool bindings, config)
  Method: Template-based generation keyed on framework (Elixir, TypeScript, Python)
  Rules:
    - Each capability in the spec maps to a tool binding in the generated code
    - Each constraint maps to a runtime guard or validation check
    - Architecture section provides structural hints to the generator
    - The generator is deterministic: same spec + same template version = same output
    - Template version is pinned and recorded in Build.template_version + Build.template_hash

Stage 3: COMPILE
  Input:  Generated source files
  Output: Compiled artifact (mix release, npm bundle, Python wheel)
  Errors: Syntax errors, type errors, missing dependencies

Stage 4: TEST
  Input:  Compiled artifact + acceptance tests from SPEC.md
  Output: TestRun with individual TestResults
  Method: For each acceptance test:
    1. Parse Given/When precondition → set up mocked tool state
    2. Send the precondition text as agent input
    3. Capture agent output + tool calls
    4. Validate output against Expected using:
       - Contains assertions (expected text appears in output)
       - Tool call assertions (expected tools were called with expected args)
       - Constraint assertions (no hard constraint was violated)
       - Negative assertions (forbidden content does not appear)

4.7 Deterministic Testing DSL (Normative)

defmodule Agentelic.Test.DSL do
  @moduledoc """
  Deterministic testing DSL for agents built from SpecPrompt specs.
  Tests are generated from acceptance criteria, not hand-written.
  """

  @type assertion ::
    {:contains, String.t()} |
    {:not_contains, String.t()} |
    {:tool_called, tool_name :: String.t(), args :: map()} |
    {:tool_not_called, tool_name :: String.t()} |
    {:escalated, boolean()} |
    {:escalation_reason, Regex.t()} |
    {:response_time_ms, :lt, integer()}

  @type mock_spec :: %{
    tool_name: String.t(),
    match_args: map(),
    return: term()
  }

  @type test_case :: %{
    name: String.t(),
    given: String.t(),
    expected: String.t(),
    mocks: [mock_spec()],
    assertions: [assertion()],
    timeout_ms: integer()
  }

  @doc "Generate test cases from parsed SpecPrompt acceptance tests."
  @spec from_spec(SpecPrompt.Spec.t()) :: [test_case()]
  def from_spec(spec) do
    for test <- spec.acceptance_tests do
      %{
        name: test.given,
        given: test.given,
        expected: test.expected,
        mocks: infer_mocks(test, spec.capabilities),
        assertions: infer_assertions(test, spec.constraints),
        timeout_ms: 30_000
      }
    end
  end
end

5. Ecosystem Integration

5.1 PULSE Loop Manifest

Agentelic is a PULSE-conforming loop under OS-010. As the engineering layer that turns SpecPrompt specs into deployable agents, its loop encodes the build → test → deploy rhythm.

Loop ID: agentelic.build_pipeline Loop name: Agentelic Build Pipeline Loop Version: 0.1.0 Owner: agentelic.com Workspace scope: required

Phases (5 canonical kinds):

Closure: consolidate_artifacts → retrieve_spec via Supabase, guarantee eventual.

Cadence: event (spec change via SpecPrompt ConsolidationEvent, manual build trigger, scheduled CI, GitHub webhook). Fallback manual.

Pipeline trigger intake: Agentelic listens for dark factory trigger events:

1. Supabase Realtime (recommended): Listen on spec.specs inserts/updates for workspace-scoped specs

2. CloudEvents webhook: Accept org.pulse.consolidation_event from SpecPrompt at POST /api/pipeline/trigger

3. GitHub webhook: Push events on spec repos trigger builds at POST /api/pipeline/github

4. MCP tool: agent_build can be called directly by agents or RuneFort chat

On trigger, Agentelic validates the source_hash matches, pulls the spec + compiled tests, and runs the full pipeline. On completion, emits ConsolidationEvent to FleetPrompt via the same transport.

Substrates:

• memory: graphonomous://workspace/{ws_id} (build history, learned heuristics)

• policy: delegatic://workspace/{ws_id} (deploy gates, compliance checks)

• audit: delegatic://workspace/{ws_id}/audit

• auth: open_sentience://workspace/{ws_id}

• transport: mcp

• time: optional

Invariants enabled: phase_atomicity, feedback_immutability, append_only_audit, outcome_grounding, trace_id_propagation.

Cross-loop connections:

• outcome_to_prism — emits OutcomeSignal (deploy success/regression) from learn_build to prism.benchmark.observe

• published_to_fleetprompt — emits ConsolidationEvent (artifact shipped) from consolidate_artifacts to fleetprompt.publish

5.2 Framework Template Versioning

Framework templates are the code generation blueprints that turn a parsed spec into source files. Template versioning is critical for deterministic builds — the same {spec_hash, template_hash} must always produce the same artifact_hash.

Template storage: Templates live in a git repository (agentelic-templates) with semantic versioning:

agentelic-templates/
├── elixir/
│   ├── mcp-server/          # MCP server template
│   │   ├── template.json    # Template manifest (version, framework, product_type, dependencies)
│   │   ├── mix.exs.eex      # Elixir template files
│   │   ├── lib/agent.ex.eex
│   │   └── test/agent_test.exs.eex
│   ├── agent/               # Standalone agent template
│   └── library/             # Hex package template
├── typescript/
│   ├── mcp-server/          # Node.js MCP server template
│   ├── sveltekit/           # SvelteKit app template
│   └── library/             # npm package template
├── python/
│   ├── mcp-server/
│   └── library/
└── CHANGELOG.md

Template manifest:

{
  "name": "elixir/mcp-server",
  "version": "1.2.0",
  "framework": "elixir",
  "product_type": "mcp_server",
  "min_spec_version": "1.0.0",
  "dependencies": {"elixir": "~> 1.17", "otp": "~> 27.0"},
  "hash": "sha256:..."
}

Version pinning rules:

• Each Build records template_version and template_hash

• Templates are immutable once published (like FleetPrompt manifests)

• New template versions require new builds — no in-place updates

• Template selection: {framework, product_type} → latest compatible template version (or explicit pin via agent.template_pin)

• Workspace-level template pins are supported for enterprise environments

5.3 Product Type Templates

Different product types (MCP servers, apps, websites, libraries) follow different build pipelines but share the same 4-stage structure:

Each product type has its own template set, but all templates consume the same SpecPrompt.Spec input. The generator adapts based on product_type — an MCP server template generates tool bindings, while a website template generates routes and components.

6. Gap Analysis & Competitive Landscape

6.1 Market Gap: The Demo-to-Production Gap

This is now the most-cited problem in the industry. LangChain's 2026 survey shows 57% of orgs have agents in production but quality (32%) and latency (20%) are top blockers. Gartner predicts 40% of agentic AI projects will be scrapped by 2027. Kore.ai writes: "Agents don't fail because they're too advanced — they fail because they're not engineered for reality." OpenAI Frontier, launched Feb 5, 2026, is the highest-profile attempt to bridge this gap — but at the cost of complete vendor lock-in. Agentelic is the open alternative.

6.2 Enterprise Agent Platforms

6.3 No-Code Agent Builders

6.4 Industry Validation

1. LangChain State of AI Agents 2026: 57% in production, 32% cite quality as #1 barrier, only 52% run offline evals. Validates Agentelic's deterministic testing thesis.

2. Gartner Prediction: 40% of agentic AI projects scrapped by 2027 due to operationalization failures.

3. OpenAI Frontier (Feb 5, 2026): Enterprise agent platform launch — validates agent builder market. Fortune calls it OpenAI's bid for the enterprise OS.

4. Anthropic Market Share: 40% of enterprise LLM spend, up from 12%. Enterprise chooses reliability over frontier — aligns with Agentelic's thesis.

5. McKinsey: Only 23% of enterprises scaling AI agents; 39% stuck in experimentation. Gap is operationalization, not capability.

6. Microsoft Agent Framework (Dec 2025): Merging AutoGen + Semantic Kernel. PwC: 8 in 10 enterprises use some form of agent AI.

7. Pricing

7.1 Revenue Projections

8. Implementation Roadmap

9. Success Criteria

[&] Ampersand Box Design — agentelic.com