The Agentic OS.
We build Agentic Applications using our own Agentic Application. AppMaking runs on an operating system for AI agents — fourteen subsystems that let agents do real work while humans keep the decisions that matter. It's built, it's running, and you can inspect it.
A platform that sells autonomy should run on it.
Anyone can put "AI agents" on a landing page. The honest test is whether the company's own software is built that way — and whether you can check.
Every build on AppMaking executes as a task graph on this system. Each stage is an agent with a role and a permission boundary; each action is validated, timed, logged, and replayable. When something goes wrong, the Monitoring Agent finds it, diagnoses it, and asks a human what to do. Agents propose. People dispose.
Fourteen subsystems.
Every one of these is implemented and used in production paths. Nothing here is a stub — where a capability doesn't exist yet, there is no subsystem pretending it does.
Agent Registry
The single source of truth for the workforce: every role, its tools, its permissions, and what it must escalate.
Event Bus
The decoupled backbone. Subsystems react to what happens without importing each other; a failing subscriber can never break the work.
Audit Log
Append-only and hash-chained. Every action is attributable and replayable, and altering history breaks the chain visibly.
Permission System
Deny by default. Three answers only — allow, escalate, deny. An unlisted capability does not exist for that agent.
Approval Workflow
The human gate. Proposals carry evidence and risk; they expire rather than auto-approve, and every decision names a person.
Tool Registry
The only sanctioned way an agent touches the world: validated arguments, permission check, hard timeout, audit, rollback.
Task Queue
Leased, retrying, dead-lettering work distribution. A worker that dies mid-task loses its lease and the work is picked up again.
Planning Engine
Goals become validated task graphs defined as data — cycles, unknown dependencies and unknown agents are rejected before anything runs.
Execution Engine
Runs the graph, parallelizes what's independent, gates approvals, retries with backoff, and records the full trace.
Memory System
Namespaced long-term recall — standards, business rules, project history — ranked lexically today, with the vector path implemented and ready.
Knowledge Base
Ranked search over our own authored documentation and architecture decisions, so agents read the rules instead of guessing them.
Agent Comms
Structured, contract-checked handoffs between agents, so a malformed exchange fails where it happens rather than three stages later.
Observability
Counters, latency distributions and per-agent health — the numbers the Monitoring Agent reads to decide whether something is wrong.
Notification System
Severity-routed and deduplicated delivery to humans, because a platform that can generate alerts faster than anyone can read them must defend attention.
What actually happens on a build.
POST /api/apps/submit
│
├─ Agent Manager resolves the goal into a validated task graph
│
├─ architect spec → blueprint written, handoff to engineering
├─ engineers code → backend, frontend and schema in parallel
├─ qa verify → runTests via the Tool Registry
├─ staff-engineer remediate → one repair attempt, revalidated
├─ agent-manager persist → code stored, QA verdict published to you
└─ devops deliver → private repo (optional: never blocks your app)
│
└─ every step: permission-checked · timed · audited · replayable
GET /api/agentic/runs/:id → the trace, the audited action
sequence, and the agent conversation
What agents are never allowed to do.
Autonomy is only safe when its limits are structural rather than aspirational. These capabilities are marked human-only in the permission system, which means no agent can hold them — the most any agent can do is ask a person:
- Deploy the platform. Production releases of AppMaking itself are a human decision, every time.
- Change the database schema. Migrations are human-only, and there is deliberately no agent tool for running one.
- Touch billing. Pricing, credits and payment logic are permanently outside agent reach.
- Delete customer data. Destructive operations require a person.
- Read production secrets. No agent path to credentials exists.
The Monitoring Agent watches the platform and can diagnose a real problem in production — and it still cannot fix one. It files the issue with evidence and opens an approval request. A monitoring loop that can silently rewrite the system it monitors is exactly the failure mode worth designing out.
The API, not the adjective.
Every subsystem exposes an API. These endpoints are public — no key, no account — because a claim you can check is worth more than one you can't:
The operator surfaces — audit trail, run traces, task queue, approvals, memory, metrics — are authenticated, since they carry customer build data and can approve an agent's proposal. They fail closed: with no operator credentials configured, they return 404 rather than defaulting open.
The same discipline ships in your app.
This isn't architecture for its own sake. The rules the platform enforces on its own agents are the rules it builds into yours: a narrow role, a permission boundary that can't be bypassed, real operations instead of invented answers, and no destructive action without confirmation.
That's why every application AppMaking generates ships a working in-app agent that only ever reaches the signed-in user's own data — and why an Agentic Application is a category with a definition, not a label.
Build on the same architecture.
Describe your idea in a few English words. Get a production-ready Agentic Application with the agents built in.