A KOD.AI product Internal alpha

Review the decision. Let AI prepare the work.

When several agents handle your work, you need to know what they want to do and why. Gorgos brings a proposed action, its checks and the relevant policy into the owner's workflow. You review the prepared output instead of reconstructing the handoff yourself.

Internal alpha for selected KOD.AI workflows. We are seeking a bounded workflow to validate with a design partner; this is not a ready-made system that runs your whole company.

Try the guided demos Discuss one workflow

1 file

the autonomy policy, read in full by the owner

Append-only

hash-chained records on selected decision paths

3 Tiers

dynamic policy: auto, owner gate, hard stop

Decision & Evidence LedgerEXAMPLE

simulated events

06:40:02
read_data → workflow contextAn agreed source supplies context. Missing information stays visible.
AUTOExample: source reference attached

Illustrative policy, no actions executed

Fixed examples, not a deployment feed

Enterprise Nervous System

See what reaches the owner before a decision.

Choose an illustrative event. Follow the proposed work, checks and approval boundary. This animation uses fixed examples; it connects no accounts and executes no actions.

INGRESSSignal Ingest

STRATEGYAI CEO Cortex

REASONINGGraph Dispatch

JUDGEVerifier Matrix

AUTHORITYOwner Cockpit

AUDITEvent Ledger

Simulated trace: Release review example

Example: owner review

[01 INGRESS]Example: a candidate fix has a test report

[02 CEO STATE]Review context and assign the release path

[03 GRAPH DISPATCH]Example: candidate → checks → staging → review

[04 VERIFIER JUDGE]Example test report attached; coverage still needs review

[05 OWNER GATE]Example policy holds promotion for the owner's decision

[06 EXAMPLE RECORD]Example: action, policy and decision reference recorded

Reasoning Graph Meta-Framework

Know who owns the next step and what evidence is missing.

A reviewed reasoning graph defines the handoffs between roles and checks. Inspect this example to see what each stage contributes. Sources, tools and permissions must be verified for your deployment.

Incident detected → Fix drafted in sandbox → test-suite verification → Staging deploy → Owner approval → Production promote.

Core Mandate

Compose role nodes, verifier passes, retries, and subgraphs declaratively.

Execution Runtime

Multi-runtime coordinator (Hermes, Claude Code, Codex, Custom).

Evidence & Verification

Graph execution trace and intermediate node proofs.

Constitutional Boundary

Bounded iteration depth and frozen configuration constitution.

The 7-Stage Operating Loop

From a problem to an output you can review.

Agree which work may run automatically, which needs your approval and which the agent must refuse. The selected policy applies to connected action paths; this example is not a universal guarantee for every tool in your company.

01. A problem arrives

An event from an agreed source starts the workflow: for example, a service error or a team update.

02. A next step is proposed

Company context and priorities inform the proposal. Missing information must remain visible.

03. The work is assigned

A reviewed workflow defines the steps and which role owns each handoff.

04. The draft is prepared

Role agents prepare a fix, report or other output within the agreed scope.

05. Configured tools are used

Only the sources, accounts and permissions connected for this workflow are available.

06. Evidence is attached

Relevant checks and their limitations accompany the proposed action.

07. You decide

Where approval is required, inspect the output and evidence, then approve, change or reject it.

Autonomous Department Fleet

Give each role a concrete output and a limit.

These illustrative role profiles show the work to assign and the evidence to review. They describe possible workflow boundaries, not five departments already operating autonomously for customers.

Prepared output

Prepare a priority proposal from agreed company context, identify missing inputs and assign a responsible role.

Measures to agree for a pilot

Tools to configure and verify

Autonomy & Gating Boundary

Internal preparation may be automatic; connected actions follow the selected owner policy.

Autonomy Controller & Supervision

You decide what it may do alone.

autonomy.yaml and the selected owner profile define permissions for connected action paths. In a pilot, test approval and refusal cases against the actual tools.

LOW RISK · TIER 1

Auto-Execute

Actions permitted automatically by the selected policy. The owner sets the scope; these examples come from our internal profile.

read_data
draft_content
deploy_staging (known repository)
propose_graph_evolution

MATERIAL / HIGH RISK · TIER 2

Owner Cockpit Gate

A prepared action and its evidence wait for your decision. Which actions require approval depends on the selected policy; these are examples from our internal profile.

place_owner_call
use_real_person_likeness
use_patient_or_client_case_study
control_operator_device

CONSTITUTIONAL · TIER 3

Hard Stop Lock

The agent is refused rather than offered an approval shortcut. Any permitted human action must take place outside this agent execution path.

sign_contract
impersonate_human
claim_clinical_outcome
modify_graph_authority

Filter Risk Tier:

Domain Channel:

Action & Capability	Domain	Autonomy Tier	Supervision Rule	Boundary to verify
`read_data`Read context from an agreed source.	internal	Example: automatic	Permitted in this example policy	Read access and source scope must be configured.
`run_test_suite`Prepare the checks required for a candidate fix.	dispatch	Example: automatic	Configured checks, not a guarantee of full coverage	Inspect the results and missing checks.
`deploy_staging`Place a candidate in an agreed staging environment.	dispatch	Example: repository-scoped	Depends on the selected owner profile and repository	Verify staging, checks and rollback before use.
`send_cold_email`An external message in the company's name.	outreach	Example: owner approval	This illustration holds sending for review	Inspect the recipient, draft and applicable consent constraints.
`promote_to_prod`Make a candidate release available to users.	dispatch	Example: owner approval	This illustration holds promotion for review	Inspect the candidate identity, checks and rollback path.
`place_client_call`Contact a person through a configured telephone service.	voice	Example: owner approval	No call is made by this simulation	Verify the account, recipient, permissions and disclosure separately.
`sign_contract`Sign a legally binding contract.	executive	Example: refused	No agent execution or approval shortcut	The human follows the organisation's separate signing process.
`use_real_person_likeness`Use an identifiable person's likeness.	outreach	Example: owner approval	Owner review does not replace the person's consent	Verify the applicable consent, rights and use before execution.
`modify_graph_authority`Widen the authority of the workflow being evaluated.	executive	Example: refused	A candidate cannot adopt wider authority through this path	Review authority changes through a separate authorised process.

Version-Controlled Contract

Inspect an illustrative policy excerpt

Autonomy boundaries are not hidden in prompts. They live in a readable, reviewable code file.

📄Illustrative autonomy.yaml excerpt

Illustrative excerpt

A shortened example. The active owner profile and actual classification must also be checked; this is not a live configuration feed.

version: 1
mode: tiered

tiers:
  low:        # example defaults; selected owner profiles also apply
    - research
    - internal_analysis
    - read_data
    - run_test_suite
    - deploy_staging
    - draft_reply
    - propose_graph_evolution
    - publish_owner_surface

  high:       # example: review required in tiered mode
    - send_cold_email
    - send_email_batch
    - place_client_call
    - promote_to_prod
    - submit_tender
    - launch_paid_ad
    - use_real_person_likeness
    - adopt_goal_proposal
    - promote_graph_version

never_auto: # example: refused agent actions
  - send_money
  - sign_contract
  - delete_production_data
  - modify_graph_authority

Fixed example, not the active policyConfirm the selected owner profile before execution

The Next Horizon of Autonomous Enterprises

Research directions beyond the first workflow.

These concept illustrations explore what might follow scoped workflow validation. They are not available features, measured outcomes or proofs of compliance.

Example scenario 1Synthetic data

Example scenario 2Synthetic data

Example scenario 3Synthetic data

Example scenario 4Synthetic data

Example scenario 5Synthetic data

Example scenario 6Synthetic data

Example scenario 7Synthetic data

Example scenario 8Synthetic data

Example scenario 9Synthetic data

Example scenario 10Synthetic data

Example scenario 11Synthetic data

Example scenario 12Synthetic data

Fixed concept illustration, no simulation running

The idea is to compare synthetic scenarios before testing a strategy in real work. The cards here are fixed illustrations, not running simulations or predictions of a business outcome.

Capacity & Efficiency Modeling

Explore assumptions, then measure your own workflow.

This illustrative model uses fixed assumptions. It does not predict savings or incidents prevented. A pilot measures preparation time, owner minutes, corrections and operating cost.

Agents assumed in this example15 example agents

3 agents (Seed)25 (Growth)100 (Enterprise)

Monthly actions assumed in this example12,000 actions

1,00050,000100,000

Fixed assumptions: 18.5 hours per agent per month, $85 per hour, records for 99.8% of actions and flags for 0.4%. These are fictional inputs, not Gorgos results. They exclude implementation and operating costs.

Hours in the illustrative workload

~278 hrs / mo

Illustrative value at $85/hour: $23,630 / month, not a saving

Actions assumed to have records

11,976

99.8% assumed recording coverage; not verification

Actions flagged in the illustration

~48 / mo

0.4% assumed flag rate; not incidents prevented

Evidence and maturity

Know what is implemented and what your pilot must prove.

Internal implementation is a starting point. It does not establish customer-scale readiness, complete integration coverage or an improvement in your business.

Internal use comes before a customer promise

Gorgos is an internal alpha developed for selected KOD.AI workflows. Public animations are illustrative, not live telemetry or evidence of a customer deployment.

Internal alpha; external workflow validation still required

Evaluate one delivery path

The internal release path connects incident handling, a candidate fix, testing, staging, approval and promotion. A pilot must verify the same boundaries against your repository and release process before a production action.

Scoped delivery path, not an autonomous company

Review the decision afterwards

Selected decision paths record the action, policy result and supporting evidence in a hash-chained ledger. This helps reconstruct who allowed an action. It does not prove that an input was true or that every integration is covered.

Tamper-evident records on selected paths

Supervision policy is readable code

The policy and owner profile make permissions inspectable. Review changes against the actual action and connected tools before widening the scope.

autonomy.yaml contract

Ask to inspect the path relevant to your process. Public demos use fictional data; acceptance requires your agreed inputs, permissions and success criteria.

Target Operations

Built for companies where an agent's mistake costs real money.

Start where an unclear handoff or approval makes work hard to supervise.

Teams already running agents

Several agents prepare work, but you have to reconstruct their handoffs to understand what they did and who allowed it.

Owners responsible for agent actions

You need to see what an agent proposes to change, which evidence supports it and whether you can refuse it before it happens.

Software delivery teams

You want a prepared fix and test evidence to reach the person responsible for release. Measure delivery time, review effort and rework before claiming an improvement.

Governance and risk teams

You need the policy and approval behind a specific action. Assess the required data and coverage for your workflow; software alone does not establish legal compliance.

Engage with us

Start with one workflow and a decision owner.

Tell us what starts the work, what output you need and which action requires your approval. We assess a shadow run using agreed activity records and read access first. You receive proposed classifications and an estimate of the approval queue. Existing controls remain your protection during observation. Duration, access, cost and acceptance criteria are agreed before a pilot.

Architected by Piotr Kram and Mariusz Kram at KOD.AI sp. z o.o. Reach out directly to info@kodai.com.pl. Evaluate time to an accepted output, review effort, corrections and operating cost before expanding the scope.

Review the decision. Let AI prepare the work.

See what reaches the owner before a decision.

Illustrative signal, output and decision

Know who owns the next step and what evidence is missing.

Inspect the steps behind an example decision

01. Signal Ingestion

02. AI CEO State Evaluation

03. Reasoning Graph Engine

04. Autonomous Departments

05. Verification & Judge Matrix

06. Owner Cockpit Gate

07. Verifiable Decision Ledger