This question has a short answer, and that is a trap. The list of tools is easy to recite and says almost nothing about the quality of what will be built. We give ours anyway, because a provider who refuses to has a problem.

What we use

  • Language models. Mainly those from Anthropic and OpenAI, chosen task by task. High volume classification does not call for the same model as writing. The choice stays reversible: the code never assumes a single vendor.
  • Programming interfaces. Those of your business tools, of advertising platforms, of messaging and payment systems. That is where the real integration work happens.
  • Database. A relational database with row level access rules, which remains the source of truth. Models read and write through it, never around it.
  • Execution. Functions deployed at the network edge, scheduled jobs and queues for anything long, expensive or likely to fail.
  • Knowledge bases. Your documents split, indexed and cited, so the model answers from your material rather than from its memory.
  • Permissions and authentication. One identity per user, roles, and entitlements verified on the server. Never in the browser alone.
  • Logging and monitoring. Every automated action leaves a readable trace with its cost, its result and its author. Alerts go out on abnormal cases.

Why the list is not the answer

Two providers can name exactly the same technologies and deliver two radically different things. What separates them fits into five questions, to be asked straight after:

  • What happens when a call fails? Retry, backoff, queue, abandon with an alert: there must be a precise answer, different from case to case.
  • Who is allowed to trigger what? An automation running under an all powerful account is an incident waiting to happen.
  • How do we know what happened? Without a readable log there is no diagnosis, therefore no correction.
  • What does it cost to run? Model cost is measured per call. An architecture that does not measure it does not control it.
  • What stays deterministic? Anything that can be a rule must stay a rule. The model only steps in where judgement is required.
The model is the most visible component of an automation. It is rarely the one that decides whether it succeeds.

On no code platforms

Platforms such as n8n, Make or Zapier are excellent tools, and we have nothing against them. They fit simple, low volume chains without deep conditional logic perfectly well. They become costly and fragile as the process grows complex, as volume rises, or when fine grained error recovery is needed.

So the real subject is not "code versus no code", but: at what point do you change vehicle, and who will tell you honestly.

One detail that changes everything: whose account the AI runs on

When we pilot your automations, model calls run on your own access, your account, your invoice. You see the consumption, you can cap it, and you can switch it off. This point sounds administrative: it actually determines who controls the tool, and it connects directly to the question of ownership.

To see how these components fit together in practice, the AI Orchestrator page describes the piloting work, and this article opens the hood.