How to Describe Your Workflow to Claude or ChatGPT Until It Outputs a Working Internal Tool
Describe workflows as constraints, not goals, then connect AI output to real infrastructure.
To build a client portal or internal tool with Claude or ChatGPT without hiring a developer, describe the workflow as explicit rules, then connect the build to managed infrastructure. The key is narrowing what the AI can assume, diagnosing wrong output, and providing the database, authentication, and hosting that a working tool needs.
Why describing a workflow is harder than it looks, and why that matters
“Write me an invoice approval tool” names a goal. It does not describe how an invoice moves through the business, who makes each decision, or what happens when the normal path breaks. Those omissions leave the model to choose. The result can look convincing while following rules nobody in the business agreed to.
A model trying to help fills gaps with guesses that seem right, and the builder may never spot some of them in the first output. Those early choices explain much of the distance between a good-looking demo and a usable tool. Claude’s no-code workflow guide frames the shift as moving from code to intent, which makes the precision of that intent the builder’s central responsibility.
The difference between a description and a constraint set, and why only one works
A description gives the model a destination. A constraint set also blocks the routes it must not take. The invoice approval request shows the contrast. Its constrained counterpart would retain the same goal but specify the required fields, approval decisions, permitted actions, exceptions, and final state. Those details must come from the business.
Constraints work in four directions, namely positive, negative, structural, and conditional. Positive constraints say what must go in, while negative constraints say what must stay out. Structural constraints define the output’s form. Conditional constraints say what happens when a given condition is met and which other path must not be taken.
Conditional rules are usually the hardest to write. They expose decisions that people make from habit but have never documented. Leaving those decisions open gives the model freedom over the logic, just as unnamed fields give it freedom over the data. That freedom produces drift across sessions because each new output can resolve the same omission differently.
How to map a real workflow before the first prompt is written
Write the workflow map before opening the AI. This is a separate document that the prompt will use. It needs to answer what a user does, what data those actions create or change, and what should happen automatically afterward. The test is whether a new employee could follow it without asking how the business works.
Start with the event that sets the workflow in motion. It might be a form submission, an email arrival, or a status change. The guide identifies this trigger as the first structural step because every later action depends on that initial “if.”
Then write numbered steps in the order a real user takes them, and annotate each with the decisions or checks required before the next step. Name fields rather than using an umbrella phrase such as “client information.” Mark which are required, which are read-only, and which change state after an action. This makes the document specific without making it technical.
Once that map exists, use it to request a plan before construction. The plan should show the files to create, the data flow, and the edge cases to handle. Compare it with the map before accepting it. Fixing a misunderstood sequence at this stage avoids spending time correcting code built around the wrong workflow.
How to structure the first prompt to build an internal tool without a developer
The first prompt needs four parts in order, which are role, constraints, data shape, and trigger-to-output chain. Each removes a different kind of guesswork. Role establishes what is being built and who will use it. “You are building an internal approval tool for a five-person finance team” provides context that “build me an approval tool” does not.
A prose skeleton can keep the structure visible. Role [tool being built and intended users]. Constraints [what the tool must do, what it must not do, output format, and conditional rules]. Data shape [what the user submits], [what the tool stores], and [what each action changes in the database]. Trigger-to-output chain [starting event], [ordered actions and decisions], and [completed state].
Fill those placeholders from the workflow map. Negative constraints deserve particular attention because an unrequested feature can look useful while expanding the tool beyond its intended job. State exclusions directly. For the data shape, give each of the three answers its own sentence so that submissions, stored records, and updates remain distinct.
Close with one complete path through the workflow. Specify the event that fires the first action, what happens at each step, and what counts as finished. The guide describes this architectural work as visualizing the sequence before construction. A complete path gives the model something more precise to build than a collection of features.
What to do when the output is wrong — diagnosing instead of rewriting
When the output misses the mark, do not immediately append another demand. First ask the model, “Before I ask you to revise this, explain to me how you interpreted the workflow I described.” Compare that interpretation with the map. The useful correction is the gap between them.
When the logic is wrong, the conditional rule needs to be fixed. If the model took the wrong branch, changing the screen layout will not repair the decision. A scope miss instead needs an explicit inclusion or exclusion. A data miss requires the field’s name, type, and relationship to adjacent fields, rather than a general instruction to fix the database.
These are different faults with different remedies. Adding instructions without locating the fault leaves the original ambiguity in place and gives the model another layer to reconcile. Diagnostic iteration changes the rule that caused the error. It does not keep stacking requests on top of an uncertain foundation.
Let the model complete its task before evaluating the result. A complete but wrong output gives more diagnostic information than an unfinished one. The next pass can then address a specific mismatch. This is where constraint-first building earns its value, because the map provides a standard against which each revision can be judged.
When two AI models outperform one — assigning draft and review roles
For tools with more complex logic, separate drafting from review. One model can build a solution while another checks it against the workflow constraints. This creates a chance to catch category errors that repeated revisions within one conversation may reinforce.
A useful pattern is ChatGPT generation, human integration, Claude review, human testing, and then merging the accepted changes. Architecture planning can also be assigned before drafting begins. Every handoff needs the same rules, data definitions, and intended outcome.
The human still owns the decision to ship. That means integrating the work, testing real paths through the tool, and deciding which changes stay or wait. With the work split this way, the human can leave the code writing to the models but must still judge their work. The reviewer needs the constraint document as its reference, rather than relying only on the first model’s explanation of its own work.
How MCP connectors turn a working prompt into a tool that touches live data
Even when a workflow is right, it still needs a way into the business systems. MCP, short for Model Context Protocol, lets AI clients that support it connect to the apps and data the workflow uses. A builder defines the server once, and compatible clients can use it without rebuilding the integration for each one.
Notion hosts an MCP server that lets Claude, ChatGPT, and other clients that support it read and write Notion pages without custom code. Zapier MCP provides actions across thousands of apps, with managed authentication and permissions controlled by the builder. These serve different connection needs. Neither removes the need to specify which operations the workflow actually requires.
Access also depends on the client and plan. Claude Desktop supports remote servers as Custom Connectors with native OAuth, through Settings, Connectors, and Add custom connector. The setup takes a server URL and a connection step, and credentials can rotate without reinstalling. ChatGPT added custom MCP support in September 2025 through Apps & Connectors, with OAuth 2.1 and Dynamic Client Registration required and bearer tokens unsupported.
ChatGPT’s full read/write MCP access through Developer mode requires Plus or above. Free tiers on Claude.ai and ChatGPT cannot add custom MCP servers. The stated entry plans are Claude Pro at $20/month and ChatGPT Plus at the same price. These requirements belong in the build decision.
With access to live data, clear constraints matter even more. Specify the fields a connector may read, the fields it may write, and what it must not touch. The same care that keeps invented features out must now set limits on what the tool does to business data. A connected model should not be left to infer its own permissions from the tool’s general purpose.
Where this approach still breaks down — and what to do about it
Constraints cannot supply definitions the business has never agreed on. If nobody can say what a field includes, excludes, or means in relation to other fields, the builder cannot describe it precisely. The model will fill that gap with an assumption.
This is a data governance problem expressed as a prompting tax. Someone has to add context by hand in each session because the source of truth was never written down. Using two models does not solve that absence. Claude and ChatGPT can interpret the same underspecified rule differently, both across models and across sessions.
For a small internal team, there is still a practical path forward. An internal tool can have more tolerance for error than a customer-facing product, and plain-English iteration can help the team improve the tool while developing shared definitions. That argument is narrower for a client portal. Internal use and customer use do not offer the same room for mistakes.
Treat the workflow map as a living document. When an iteration exposes a wrong assumption, record the correct definition there. Each correction then reduces the context that must be supplied again. The constraint document stays the point of reference no matter which model made the latest version.
What production-ready internal tools built this way actually need from infrastructure
The tool outgrows the conversation when another user needs it. Backend logic must have somewhere to run, records must be kept between sessions, and authentication must control who gets in. Recurring tasks and a stable URL are also part of the working system.
For a non-technical owner, assembling that infrastructure becomes a second job. Server configuration, deployment pipelines, and separate external services take time that even a precise prompt cannot save. The build may get the business right and still be hard to run. That is why infrastructure belongs in the decision about how to build, rather than being deferred until the screens look finished.
An MCP-native managed infrastructure layer can meet those needs from within the conversation. The AI client connects to a service that handles the backend, database, authentication, hosting, and notifications automatically. An all-in-one approach reduces the separate systems the founder must assemble. Its value is not another generation feature, but a shorter route from approved logic to a usable tool.
Pricing needs to be checked as closely as features. A misconfigured loop can generate large surprise charges under per-task billing, while flat, predictable infrastructure pricing removes that particular billing risk. With a complete workflow description and managed infrastructure, the gap to a running tool should be minutes.
