Cohesive Systems logoCOHESIVE SYSTEMS

Search Cohesive Systems

Ready

Search Cohesive Systems

Find product pages, building blocks, technical articles, and graph definitions.

Vision

Start with the overview, then choose the lens you need.

Cohesive & AI

Build with agents. Interact through agents.

A shared account of system meaning helps agents change software, answer questions, and participate in running processes with explicit authority and feedback.

One System, Two Uses

Both pillars start with the semantic system graph. It connects the system's definitions, relationships, rules, actions, and evidence.

For a specific task, Cohesive gathers the relevant definitions and dependencies. Shared identities keep that local context connected to the rest of the system, so tooling checks a proposed change or action against rules defined elsewhere.

The Two Pillars

Pillar 1

Agentic development

Agents work through their development harness to inspect semantic source, propose edits, consume compiler diagnostics, review affected behavior, and verify supported outputs and hand-written integrations.

Pillar 2

Agentic interaction

Agents receive selected observations and actions. They can answer a question, request a change, or participate in a process alongside people, services, and deterministic computation.

Agentic development changes the system's definition and implementation. Agentic interaction works through the actions and processes the system already offers. The graph gives each agent the context and access its role needs.

An agent decision can be an explicit step in a process. For example, an agent can examine a refund request and recommend an outcome. The surrounding process states who may approve it, when to escalate, how the accepted decision is recorded, and how work resumes after a failure. Recovery must account for the possibility that asking the model again produces a different answer.

These are the roles the language and tooling are designed to support. Available generation targets and runtime integrations vary by building block. The development landscape explains how Cohesive fits alongside coding harnesses and software factories.

Keep Authority Explicit

An agent can recommend, propose, request, or attempt an action. The authority to accept it stays with a declared person, policy, protocol, or entity transition.

The system states what an agent may observe, which actions it may select, which policies apply, what evidence is required, and where another authority must decide.

Each action also leaves useful evidence. A successful tool call records the call. The system also needs evidence for the transition, effect, or process that the call was meant to complete.

Keep Accepted Changes Deterministic

Agents can explore, explain, and propose changes in natural language. Once a change is accepted, it moves into versioned Cohesive artifacts as durable system knowledge.

Models explore possible interpretations and implementations. Mechanical compilation resolves accepted artifacts into graph state, reports diagnostics, and produces supported code and runtime artifacts. The same source, compiler version, configuration, and declared inputs produce the same result.

Reproducibility is one property of that result. Tests, analysis, and observations provide evidence about whether the definitions are appropriate and their realizations behave as required.

Existing code can still produce candidate graph models for migration and audit. Those models begin as evidence about what the implementation does. They become authoritative only after they are reconciled with accepted system intent.

Give Agents A Feedback Loop

An agent investigating a stalled refund needs observations from the running system: which transition committed, whether the payment provider accepted the request, and which process is waiting. Traces, metrics, logs, and domain observations supply different parts of that evidence.

Connecting observations to semantic identities lets an agent investigate a discrepancy, propose a change or request an authorized action, then check its effect. The useful outcome is evidence that the refund progressed as intended, beyond a successful tool response or a passing local test.

This feedback also has limits. Missing telemetry leaves uncertainty, and a successful trace supports a claim about that execution. Source revisions, provenance, and assumptions keep that evidence interpretable as the system changes.