Our Process
Artcompiler builds smart tools that let AI agents use APIs safely and reliably. This note describes how we get there: the architecture each smart tool follows, the languages that make it possible, and the principles we apply as we move from idea to message-market click.
WHAT WE BUILD
A smart tool is a web service wrapped by a domain language wrapped by a specialized AI. Each tool is exposed to agents through an MCP server and renders its output through an embeddable runtime. The full vertical slice looks like this:
Any agent → MCP server → specialized AI → domain language → embeddable runtime
We are not building thin API wrappers. We are building tools where the domain language is the intelligence layer. The language carries the domain knowledge, constrains what the agent can express, and gives us a clean surface to validate, render, and reason about every call an agent makes.
WHY LANGUAGES MAKE AGENTS SAFE
APIs were designed for human developers reading documentation. Agents read context and pattern-match. Hand an agent a raw API and you get plausible-looking calls that are wrong in ways that are hard to detect.
A domain language sits between the agent and the underlying service. It expresses only the operations that make sense in the domain, parses into a typed and checked intermediate form, and refuses inputs that don't compile. That gives us three properties agents need:
- Safety. Malformed or out-of-domain requests fail at the language boundary, not in the service.
- Reliability. A specialized AI trained on the language produces output that compiles, runs, and renders predictably.
- Inspectability. Every call an agent makes is a small, readable program in the domain language — easy to log, replay, and review.
For how this is enforced — capabilities, policies, grants, and the checker/transformer split — see How Graffiticode Keeps Agents Safe.
OUR DOMAINS AND TOOLSETS
We organize work into domains — problem spaces with real demand and repeatable patterns. Working in distinct domains lets us compound our investment in language design, runtime components, and specialized AI training across every tool we ship.
Within each domain we build toolsets — collections of smart tools aimed at a specific audience of creators. Assessments is our toolset for authoring assessments. Sheets is our toolset for embeddable spreadsheets. Each toolset has its own subdomain, audience, and path to monetization, all under the Artcompiler brand.
OUR TECH STACK
Every smart tool is built on Graffiticode — our open source platform for creating and deploying language-oriented MCP servers with specialized AIs.
Graffiticode uses React on the frontend and Node.js on the backend, with a domain language in the middle. The language is what makes a smart tool more than an API wrapper: it is the shared substrate that the specialized AI generates, the runtime executes, and the MCP server exposes to agents.
Because Graffiticode is open source, the architecture is auditable, the languages are inspectable, and the developer community can extend the platform alongside us.
HOW WE WORK
Three constraints shape every smart tool we build:
- The language comes first. Before we wrap a service we design the language that will sit in front of it. If we can't express the domain cleanly, we don't yet understand it well enough to ship.
- The specialized AI is trained on the language, not the API. The model's job is to produce well-formed programs in the domain language. The language and its compiler do the rest.
- The runtime renders what the language describes. UI is a function of the program, not a separate concern. Every tool ships with an embeddable runtime so the same program runs anywhere an agent or a human can reach it.
Our objective for each smart tool is the same: a simple, lovable, and complete slice of a domain that an agent can use safely and a human would choose to use directly.