Why ModuleX has no integration setup screen

There is a moment near the start of every integration platform where you are asked to set up your tools. A grid of logos, a series of OAuth prompts, and a quiet assumption that you already know which of them this is going to need.

We do not have that step, and the reasoning behind its absence is worth writing down — partly because it looks like a missing feature until you see what replaces it.

The setup screen asks the wrong person

A connection screen asks you to predict which services the work will touch. That is a strange request. You know what you want done; the mapping from that to a set of connectors is exactly the thing you were hoping not to have to think about.

Worse, it is asked at the point of lowest information. You have not run anything yet. You do not know whether the task you have in mind is one tool or three, and you will not find out until after you have finished guessing.

So people over-connect. They authorise six services because five felt too few, and most of those grants sit unused — which is a security posture nobody chose and a first ten minutes spent on admin.

Committing early and carrying the commitment forward has a measurable cost in a neighbouring setting. A July 2026 preprint on binding drift found that when an agent's early choice of which entity to act on was wrong, pinning that choice and carrying it forward multiplied downstream wrong actions by 3.0× on average across eight model backends, and by 8.5× on the worst-affected one. That measures entity binding inside a run rather than connectors chosen at signup, and the wrong choice was deliberately seeded — but the shape is the same one: a decision made at the point of least information, then honoured by everything after it.

Let the task raise the request

The ModuleX assistant asks for a service at the moment it needs one. You describe the work; it starts; and when it reaches a tool it cannot get to, it stops and tells you which one and why.

That is not a special case bolted on for onboarding. It is one of a small set of things the assistant can pause and ask for — a choice, a yes or no, some text, or access to a service. The same pause mechanism that requests a credential is the one that asks for approval before it acts. Access is just another thing it does not have and will not proceed without.

The practical effect is that the connector list stops being a prediction and becomes a record. After three real tasks you have connected exactly the tools your work actually crosses, and nothing else.

Failure has to be structured, or it is worse than nothing

The part of this we spent the most time on is the least visible: what happens when connecting fails.

An expired token, a denied OAuth prompt, a popup closed by accident. The tempting design is to treat a failed connection as an absence and carry on — the run continues, does what it can, and reports something that looks like success.

That is the worst available outcome. A silent credential failure is how automations end up appearing to work while doing nothing, and the failure surfaces weeks later as "I thought that was running."

This happens in production, and the reported cases are worse than the phrasing suggests. Dan Musetoiu of Romania's Agency for Financing Rural Investments has described a live assistant where one unset configuration parameter silently truncated the head of every over-long prompt — cutting the behavioural rules and every guard out of the request, with no error raised — for weeks, while the operators attributed the symptoms to the model being weak rather than to a setting nobody had set. It is a single documented incident rather than a measured frequency, and the specific parameter is a local-runtime detail; the mechanism generalises further than the setting does.

So a failed connection is handed back as a structured result rather than swallowed: what went wrong, and whether it is worth retrying. The assistant can then tell you plainly, or try again, instead of proceeding on access it does not have. Being clearly stuck is more useful than being quietly wrong.

What we gave up

This is not free, and two costs are real.

There is no "set it all up on Monday" flow. A team that genuinely wants to connect its whole stack in one sitting has to do it through use rather than through a checklist, and for some organisations — the ones where one person provisions access for everyone else — that is a worse fit than a setup screen.

Discoverability suffers. A grid of logos advertises what is possible. A system that asks only when it needs something never shows you the tools you did not think to ask about. Our answer is the integrations directory and the use-case library doing that job as browsing surfaces rather than as gates, but it is a genuine trade and not obviously the right one for everybody.

The underlying principle

Configuration that a system can determine at the moment it matters should not be requested in advance from someone with less information.

That is the whole idea, and it is the same instinct behind not having an approvals settings page. In both cases the alternative is a screen that asks you to predict something, and then quietly holds you responsible for the prediction being wrong.

If you want to see where it lands, the first-tool guide is the short version: pick a task you actually did this week, ask for it, and let the request tell you what it needs.