About Createting

We build infrastructure for AI systems that are allowed to act.

Models can already write, reason, speak and operate software. The harder problem begins when those capabilities touch real company data, tools, customers and decisions. Createting is building the operating layer around that work: context, execution, authority, orchestration and evidence.

The goal is not maximum autonomy. It is useful autonomy inside an architecture a company can understand, constrain and improve.

CompanyCreateting Platforms UG
Location95028 Hof
Represented byCanberk Gencay

Why this company exists

AI stops being a demo when it can change an external system.

A useful business agent needs more than a prompt and a model. It needs the right context, bounded tools, state that survives a single turn, a way to ask for approval, a reliable execution path and evidence that the intended outcome actually happened.

That is why Createting is being built as a platform plus an implementation and infrastructure layer rather than as another isolated chatbot or workflow template.

Product principles

Mechanisms before adjectives.

These principles shape both the platform and how we approach customer work. They also define what we should be willing to show publicly.

01Start with the workflow.

Choose deterministic automation, an agent, a governed mission or a hybrid because the work requires it—not because one architecture sounds more advanced.

02Authority follows the action.

A read, a refund and a contract change should not inherit the same level of autonomy merely because one agent can technically request all three.

03One runtime, bounded capabilities.

Voice, browser, tools, knowledge and delegated workers should share the same operating controls instead of becoming disconnected automation islands.

04Evidence before expansion.

Scale what produces a measurable outcome under explicit constraints. Do not turn a promising demo into a broad deployment before the failure modes are understood.

05Architecture includes economics.

Model choice, routing, context, infrastructure and deployment shape cost as much as the application layer does.

06Say less. Prove more.

Benchmarks, product state and deployment boundaries should be distinguishable from targets, configured examples and future work.

What Createting is building

One company. Three connected layers.

01 · PLATFORM

Build, coordinate and operate agents.

Agent Studio, Orchestrator and Mission Control connect models, knowledge, tools, workflows, approvals and execution surfaces inside one agentic platform.

Explore AI Agents
02 · CONSULTING

Design the operating model before scaling it.

Map high-value workflows, decide where AI should act, define integrations and authority boundaries, and scope a controlled pilot around measurable evidence.

Explore Consulting
03 · INFRASTRUCTURE

Run each workload on the right model and deployment layer.

Evaluate API, hybrid, dedicated and private options around capability, data, economics and operational requirements. Fine-tuning is used when evaluation shows it is justified.

Explore Infrastructure

How we work

Start narrow. Learn from real execution.

A smaller, measurable workflow usually produces more useful evidence than a large “AI transformation” program that cannot isolate what worked.

01
Map the process

Outcome, actors, systems, variability and current failure cost.

02
Choose the operating model

Workflow, agent, mission or hybrid—plus the capability and model requirements.

03
Define authority

Data access, tools, approvals, denied actions, escalation and evidence.

04
Run a controlled pilot

Measure the actual workflow under explicit validation criteria and operational safeguards.

05
Scale or stop

Expand what creates measurable leverage; reject weak economics or unreliable behavior.

A note on product status

We separate architecture direction from deployment evidence.

Createting is actively developing and hardening a broad agent runtime. A feature existing in the product architecture is not automatically proof that every deployment pattern is production-validated. Public claims should stay tied to current product behavior, completed testing and the configured environment.

Explore the work

See how the platform turns those principles into an operating system for agents.

Or start with one workflow and determine whether it should be automated, agentic, mission-driven or hybrid.

Security architecture · current implementation boundary

Control the action before it becomes an incident.

Createting’s security model is built around tenant boundaries, scoped agent identity, pre-execution policy decisions, approval binding and evidence. This page describes mechanisms present in the current architecture—and states where validation or production hardening is still environment-dependent.

Current code-backed mechanisms≠ certification claim

Pre-execution boundary

An action is described before authority is decided.

Runtime actions can carry the action type, target resource, arguments, side-effect state, external/sensitive flags, risk hints, expected effect, data-access summary and target system. The policy gate then returns an explicit decision rather than treating every tool invocation as equivalent.

ACTION DESCRIPTORconfigured example
action
crm.update_account
effect
external write
risk
high restriction
decision
ASK
binding
approval fingerprint
DescribeClassifyPolicyApprove / denyExecute

Security controls

Separate controls for identity, data boundary, execution and evidence.

01

Tenant context and workspace boundaries

The current Arch2 data plane includes tenant context checks, membership validation and an RLS coverage audit for tenant-scoped tables. The audit can detect missing RLS, missing forced RLS and missing canonical tenant policy instead of assuming isolation is complete.

implemented mechanism
02

Agent identity and delegated work

The architecture includes an agent-identity layer with JWT, DPoP and delegation primitives. Delegated system-agent work is designed to retain an attributable identity rather than collapsing every action into one anonymous backend actor.

implemented foundation
03

Action-level authority

The shared ActionPolicyGate covers tool, knowledge, web search, memory write, browser, computer, external API, subagent and artifact actions. Decisions can allow, request approval, deny or hard-deny based on capability state, autonomy and risk.

Deep dive →
04

Approval is bound to the prepared action

Approval snapshots are fingerprinted from the action descriptor. A resumed approval can therefore be checked against the prepared action instead of silently authorizing a different replanned request.

decision binding
05

Sandboxed and environment-bound execution

The architecture contains persistent workspaces, sandboxed execution, snapshots and staging promotion. Browser and computer sessions are modeled as agent-bound runtime capabilities with recovery, cleanup and environment trace events.

Browser boundary →
06

Durable state and evidence

Durable execution, typed state, checkpoint write-through, execution traces and a compliance ledger provide mechanisms for retaining operational context and evidence. Retention and legal-hold behavior still depend on the configured deployment and policy.

evidence layer

What this does not claim

Architecture controls are not the same thing as external assurance.

No certification shortcut.

This page does not claim SOC 2, ISO certification, GDPR compliance or another external certification solely because technical controls exist.

No universal production-ready claim.

Current architecture documentation still marks parts of environment operations and governed runtime hardening as in progress or production-hardening open.

No environment-free security claim.

Secrets, provider configuration, deployment topology, identity provider setup, network policy and operational procedures affect the real security posture.

No “zero-risk” language.

Governance reduces and constrains risk; it does not make autonomous execution infallible.

Current architecture status

Implementation status is part of the security story.

AreaCurrent repository statusBuyer interpretation
Tenant isolation / RLS auditImplementedMechanism exists; deployment audit still matters.
Agent identityImplemented foundationIdentity/delegation primitives exist.
Sandbox workspaceImplementedSandbox, snapshots and staging mechanisms exist.
Browser / computer environmentsRuntime slice in progressValidate provider and environment behavior for the target deployment.
Governed runtime decision bindingDEV_READY; production hardening openDo not treat development readiness as external assurance.

Evaluate the boundary

Start with one consequential workflow.

Map the systems it touches, the writes it can perform, the approval owner and the evidence required after execution.