System: MWMS
Document Type: Operating Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.1
Primary Location: MCR
Future Operational Destination: Automation Brain, HeadOffice Brain, AIBS Brain, Product Brain, Data Brain, Compliance Brain, Risk Brain, Development Governance, Client Delivery Systems
Parent Page: Automation Brain
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-14
Source / Origin: AI Automations by Jack AI Native Entrepreneur Architecture And Tool Decision Block And Make Workflow Modularity Block
MWMS Classification: Automation Architecture Framework / Tool Selection Framework / No Code Versus Code Decision Standard / AIOS Build Governance Framework / Client Delivery Architecture Standard / Reusable Integration Component Standard / Workflow Modularity Standard
Primary Brain: Automation Brain
Supporting Brains: HeadOffice Brain, AIBS Brain, Product Brain, Data Brain, Compliance Brain, Risk Brain, Sales Brain, UX Brain, Research Brain, Finance Brain, Experimentation Brain
Related Pages: MWMS Micro SaaS Productization And Access Control Framework, MWMS Client Intelligence And Business Memory Automation Framework, MWMS Productized AIOS Service Packaging And Scope Control Framework, MWMS AI Automation Security And Risk Checklist, MWMS AI Usage And Cost Visibility Standard, MWMS AI Tool Permission And Access Framework, MWMS AIBS Business Diagnostic And Opportunity Discovery Framework, MWMS Prompt Architecture And Automation Output Reliability Framework, MWMS AI App Builder And Productized Interface Framework, MWMS AI Tool Access Browser Automation And MCP Governance Framework
Purpose
The purpose of the MWMS Automation Architecture And Tool Selection Framework is to define how MWMS chooses the correct automation, AI, database, interface, hosting, integration and development architecture for each internal system, client system, productized AIOS module or future micro SaaS product.
This framework exists because the AI automation landscape creates constant tool temptation.
MWMS will repeatedly face questions such as:
Should this be built in n8n?
Should this be built in Make?
Should this be built with Claude Code?
Should this be built in Lovable?
Should this be a Supabase-backed product?
Should this use Airtable or Google Sheets?
Should this use a browser automation tool?
Should this be locally hosted?
Should this use direct APIs?
Should this use MCP?
Should this be a manual workflow first?
Should this be a custom-coded system?
Should this use a raw HTTP request?
Should this use a reusable custom connector?
Should this be split into several sub-workflows?
Should this store intermediate state?
Should this be built at all?
This framework prevents MWMS from chasing tools because they are new, popular, cheap, impressive or heavily promoted.
The core purpose is:
To help MWMS choose the right build architecture for the business problem instead of forcing every problem into the latest tool.
Core Doctrine
The MWMS doctrine is:
The business problem chooses the architecture. The tool does not choose the business problem.
MWMS must never begin with:
“Let’s use n8n.”
“Let’s use Claude Code.”
“Let’s build it in Lovable.”
“Let’s use MCP.”
“Let’s automate the browser.”
“Let’s make an AI agent.”
“Let’s self-host it.”
“Let’s turn this into an app.”
“Let’s create a custom connector.”
“Let’s split it into multiple scenarios.”
MWMS must begin with:
What problem are we solving?
Who owns the problem?
What outcome matters?
What data is needed?
What risk exists?
How often does it run?
Who uses it?
How reliable must it be?
How visible must it be?
How supportable must it be?
What is the simplest safe architecture?
The key doctrine is:
Tool choice is a consequence of diagnosis.
Strategic Importance
This framework is strategically important because MWMS is becoming a multi-Brain, multi-system and multi-employee ecosystem.
That means tool decisions will become more frequent and more dangerous.
Without a decision framework, MWMS risks:
overbuilding simple systems
underbuilding critical systems
choosing tools based on hype
creating fragile automations
building systems M cannot maintain
confusing client-facing products with internal workflows
using browser automation where an API should be used
using no-code where proper code is required
using code where no-code would be faster
repeating raw HTTP work across many workflows
creating duplicate integration logic
building oversized scenarios that are difficult to debug
hiding workflow state inside unclear routing
creating security risks
increasing tool costs
adding support burden
creating unclear ownership
creating systems that cannot scale
creating systems that cannot be handed over
This framework creates a disciplined path.
The strategic standard is:
MWMS should build measurable systems, not impressive diagrams.
Definition
Automation architecture means the complete structure used to deliver a system, including trigger, data source, automation engine, AI model, database, interface, user access, reporting, hosting, security, maintenance, integration boundaries and workflow state.
Tool selection means choosing the correct tool or combination of tools for the specific business problem.
No-code architecture means using tools such as n8n, Make, Airtable, Google Sheets, Supabase interfaces or visual automation builders to create workflows without traditional software development.
Code architecture means using custom development, Claude Code, Cursor, Python, JavaScript, TypeScript, APIs, custom plugins, custom connectors or server-side logic to create a more controlled system.
Hybrid architecture means combining no-code, AI coding tools, databases, APIs, reusable connectors and human review to get the right balance of speed, reliability, control and cost.
Reusable integration component means a governed connector, custom module, sub-workflow or API wrapper that standardises repeated interaction with an external system.
Workflow state means the intermediate values, statuses, calculations and outputs that must be preserved and reused as a workflow progresses.
MWMS Definition
The MWMS Automation Architecture And Tool Selection Framework is:
Automation Brain’s standard for deciding which tools, platforms, hosting models, interfaces, databases, development approaches, reusable integration components and workflow structures should be used for each MWMS or client system based on business outcome, complexity, reliability, risk, cost, ownership and long-term maintainability.
Scope
This framework applies to:
internal MWMS automations
AIBS client systems
AIOS productized systems
client dashboards
micro SaaS products
lead capture systems
outreach systems
review systems
content systems
RAG systems
voice agent systems
browser automation workflows
Supabase systems
WordPress systems
n8n workflows
Make scenarios
Airtable systems
Google Sheet automations
Lovable MVPs
Claude Code projects
locally hosted automation systems
cloud-hosted automation systems
API integrations
custom Make modules
custom n8n nodes or reusable workflows
webhook-linked workflows
MCP tool access
custom-coded tools
prototype systems
production systems
future AI Employee operational systems
This framework does not provide step-by-step development instructions.
It governs decision-making before development begins.
Core Principle
The core principle is:
Choose the simplest architecture that can safely, reliably and profitably deliver the required outcome.
Simple does not always mean basic.
Simple means:
fewer moving parts
clear ownership
clear data flow
low failure risk
easy debugging
appropriate security
manageable cost
user-friendly interface
supportable by the MWMS team
aligned with the business goal
Complex architecture is allowed only when the problem genuinely requires it.
Rule
Do not add technical complexity unless it creates measurable business value, improves maintainability or reduces meaningful risk.
The MWMS Automation Architecture Decision Model
Every MWMS automation architecture decision should be evaluated across twelve layers:
- Business Outcome Layer
- User And Operator Layer
- Data Source Layer
- Workflow Complexity Layer
- Tool Fit Layer
- Interface Layer
- Database And State Layer
- AI Model And Prompt Layer
- Hosting And Infrastructure Layer
- Security And Compliance Layer
- Cost And Maintenance Layer
- Scale And Upgrade Layer
- Business Outcome Layer
Every tool decision begins with the business outcome.
Business Outcome Questions
Ask:
What problem is being solved?
What business result should improve?
Is the goal to save time?
Is the goal to make money?
Is the goal to reduce risk?
Is the goal to improve follow-up?
Is the goal to improve reporting?
Is the goal to improve decision-making?
Is the goal to improve customer experience?
Is the goal to create a sellable product?
Is the goal internal productivity or client delivery?
How will success be measured?
Outcome Types
Common MWMS outcomes include:
faster lead response
better client diagnosis
fewer missed leads
better content production
better reporting
better customer support
better review collection
cleaner data
better sales follow-up
reduced manual work
higher conversion
stronger client visibility
more reliable operations
Rule
If the outcome is unclear, do not choose a tool yet.
- User And Operator Layer
A system must fit the people who use it and maintain it.
User Types
Users may include:
Martyn
M
future MWMS employees
client business owners
client staff
sales teams
content operators
support staff
local business owners
agency partners
consultants
internal AI Employees
external customers
Operator Questions
Ask:
Who uses the system?
Who maintains the system?
Who fixes it when it breaks?
Who approves outputs?
Who sees the dashboard?
Who owns the data?
Who is responsible for support?
Is the user technical?
Does the user need a simple frontend?
Can the user tolerate tool complexity?
Does M need to be involved?
Can this be managed manually first?
Will more than one operator reuse the same integration?
Would a reusable module reduce operator error?
Rule
A tool is only suitable if the users and operators can realistically use, understand and maintain it.
- Data Source Layer
Architecture depends heavily on the data source.
Data Source Types
Sources may include:
web forms
Google Sheets
Airtable
Supabase
WordPress database
Google Drive
Gmail
CRM
GoHighLevel
YouTube
RSS feeds
websites
PDFs
call transcripts
voice agent logs
chat history
customer reviews
public web pages
private client systems
APIs
uploaded files
manual input
browser-extracted data
Data Source Questions
Ask:
Where does the data come from?
Is it public or private?
Is it structured or unstructured?
Is it reliable?
Is it current?
Is access approved?
Is an API available?
Is browser automation required?
Is the data sensitive?
Does it need storage?
Does it need retrieval later?
Does it need deletion?
Does it need source tracking?
Does the API expose one action or many reusable actions?
Will the same endpoint be used repeatedly?
Rule
Data access method should be chosen before automation tool choice.
- Workflow Complexity Layer
Some workflows are simple. Others are complex.
The tool must match the complexity.
Simple Workflow Examples
Simple workflows include:
form submission to email
spreadsheet row to AI summary
RSS feed to draft content
completed job to review request
new lead to CRM record
uploaded file to folder move
These may fit:
Make
n8n
Zapier
Airtable automation
Google Apps Script
simple WordPress logic
Complex Workflow Examples
Complex workflows include:
multi-step client intelligence reports
AI agents with multiple tools
RAG systems
voice agents with fallback logic
browser automation with session handling
paid micro SaaS products
client portals
user access control
subscription logic
multi-tenant systems
complex approval workflows
many repeated API operations
cross-workflow orchestration
workflows with extensive intermediate state
These may require:
n8n
Supabase
custom code
Claude Code
WordPress plugin logic
backend functions
proper database schema
reusable integration components
dedicated QA
human review workflows
Workflow Decomposition Questions
Ask:
Is the workflow doing too many unrelated jobs?
Can one part be reused elsewhere?
Can one step fail independently?
Would separation make testing easier?
Does one part require different permissions?
Does one part have a different owner?
Does one part run at a different frequency?
Would a sub-workflow reduce duplication?
Would splitting the workflow increase unnecessary latency or failure points?
Rule
Workflow complexity determines whether no-code is enough, whether the workflow should be modularised or whether proper development is required.
- Tool Fit Layer
Each tool has a role.
MWMS must not confuse the role of each tool.
n8n
Best for:
complex workflows
self-hosted automation
API-heavy processes
AI agent workflows
reusable workflows
technical operators
internal MWMS systems
more control than Make
sub-workflow execution
complex data transformations
Weaknesses:
steeper learning curve
can become messy
requires good naming and structure
needs hosting or cloud cost
requires technical discipline
Use n8n when:
workflow complexity is medium to high
API control matters
ownership matters
long-term maintainability matters
MWMS wants more control
client data flow needs structure
sub-workflows or reusable workflow components are important
Make
Best for:
fast visual automation
simple to medium workflows
quick client demos
simpler SaaS integrations
non-technical visibility
rapid prototyping
reusable custom app modules for repeated APIs
visual operator access
Weaknesses:
can become fragile
scenarios can sprawl
costs can rise
less flexible for advanced architecture
harder for complex agent systems
routing can become excessive
intermediate state may require awkward workarounds
Use Make when:
speed matters
workflow is simple
integration support is strong
client can understand the scenario
fast proof of concept is needed
custom modules can simplify a repeated API pattern
Avoid Make when:
simple calculations require excessive routers, aggregators and state workarounds
workflow state becomes difficult to follow
scenario chaining creates excessive operational risk
the workflow becomes hard to document or hand over
Zapier
Best for:
very simple integrations
common SaaS connections
non-technical users
fast business workflows
Weaknesses:
expensive at scale
limited for complex systems
less ideal for MWMS deep architecture
Use Zapier when:
client already uses it
workflow is simple
speed matters more than control
Claude Code
Best for:
custom app development
structured code projects
moving beyond no-code
building reusable logic
repairing or extending code
controlled development
developer-assisted systems
custom connectors where visual platforms become limiting
Weaknesses:
can create risk if unmanaged
needs version control
needs testing
not for casual copy-paste operation
may create hidden technical debt
Use Claude Code when:
no-code is no longer enough
custom logic is needed
proper files and versioning are required
the project is moving toward production
reusable connector logic requires stronger testing and control
Lovable
Best for:
quick MVPs
client-facing prototypes
simple web apps
interfaces over automations
dashboards
proof of value
quick product demos
early micro SaaS prototypes
Weaknesses:
can create fragile prototypes
may require proper development later
can burn credits through debugging
not ideal for complex production systems without review
requires careful backend integration
Use Lovable when:
the interface matters
a quick demo is valuable
user experience needs to be visible
a client-facing product needs a first version
Supabase
Best for:
structured database
authentication
vector storage
app backend
user records
chat history
secure data layer
micro SaaS infrastructure
client memory systems
persistent workflow state
Weaknesses:
more technical than Airtable
security must be handled carefully
service role keys are sensitive
poor schema design creates problems
Use Supabase when:
database structure matters
user authentication is needed
app backend is needed
RAG or vector storage is needed
MWMS needs a more serious system than a spreadsheet
persistent state matters across workflows or sessions
Airtable
Best for:
flexible data organization
quick dashboards
content libraries
manual review queues
lightweight client systems
prototype databases
non-technical operations
Weaknesses:
not always ideal for production apps
permissions can become complex
API limits may matter
not ideal for sensitive or high-scale systems
Use Airtable when:
visibility matters
data is semi-structured
manual review is needed
quick operational interfaces are useful
Google Sheets
Best for:
simple logs
early testing
manual workflows
low-cost prototypes
client-visible simple data
export and import workflows
Weaknesses:
weak permissions
poor production architecture
can become messy
not ideal for sensitive systems
unreliable as core app backend
Use Google Sheets when:
the system is early-stage
manual review is required
data volume is low
simplicity matters more than scale
Browser Automation Tools
Examples:
Airtop
Axiom
browser agents
web automation agents
Best for:
websites with no useful API
form filling
controlled scraping
visual browser tasks
human-like navigation
short-term workflow bridging
Weaknesses:
fragile
platform terms risk
account ban risk
session issues
authentication risk
expensive at scale
must be monitored
Use browser automation only when:
no API exists
permission is clear
risk is reviewed
workflow is bounded
human review is possible
platform terms are considered
MCP
Best for:
flexible tool access
AI tool discovery
Claude or ChatGPT connected to external capabilities
exploratory tool use
advanced agent workflows
Weaknesses:
reliability concerns
harder to predict
security risk
tool misuse risk
not always production-safe
can be slower than direct workflow building
Use MCP when:
flexible tool access matters
the task is exploratory
strict deterministic outputs are not required
security and permissions are controlled
Direct API
Best for:
reliable production workflows
predictable data exchange
secure integrations
scalable systems
clean logging
better error handling
building reusable connectors
Weaknesses:
requires technical setup
requires documentation reading
API changes can break workflows
credentials must be managed
Use direct APIs when:
reliability matters
the platform provides an API
volume is meaningful
automation needs to scale
browser automation would be risky
the same operation will be reused across multiple systems
Raw HTTP Request
Best for:
initial API exploration
single-use integrations
early prototypes
testing endpoints
checking request and response behaviour
low-frequency operations
Weaknesses:
repeated manual configuration
duplicate authentication setup
inconsistent field naming
poor operator usability
higher risk of malformed payloads
harder handover
Use raw HTTP when:
the integration is being proven
only one or two calls are needed
the API may not become a permanent dependency
the workflow is internal and low risk
Avoid repeated raw HTTP when:
the same request is copied across many workflows
multiple operators need to configure the call
input validation matters
the integration becomes client-facing
the endpoint becomes a core MWMS capability
Reusable Custom Module Or Connector
Best for:
repeated API operations
standardised inputs
multiple operators
client delivery
clear labels and help text
validated values
consistent authentication
predictable outputs
reduced configuration errors
Weaknesses:
requires design and maintenance
API changes may require connector updates
publication creates support obligations
incorrect abstraction can hide important technical behaviour
Use a reusable custom module or connector when:
the API action has been proven
the same endpoint is used repeatedly
input fields are stable
validation is valuable
operator usability matters
the connector will reduce duplication
MWMS or clients will reuse it
Do not create a reusable connector when:
the API is unstable
the workflow is temporary
only one call is required
the action is still being explored
no one will maintain it
Local Hosting
Best for:
privacy-sensitive systems
local data control
specific client security requirements
testing local AI or local n8n
controlled environments
Weaknesses:
computer must stay on
security burden increases
uptime responsibility increases
troubleshooting burden increases
not always worth the cost savings
Use local hosting when:
privacy or client requirement justifies it
the operator understands the maintenance burden
downtime is acceptable or managed
local control is more important than convenience
Cloud Hosting
Best for:
availability
client-facing systems
production systems
remote access
stable automation
team access
scalable infrastructure
Weaknesses:
monthly cost
data hosted externally
security configuration required
vendor dependency
Use cloud hosting when:
uptime matters
remote access matters
client-facing systems are involved
system must run without Martyn’s computer being on
- Interface Layer
The interface changes perceived value.
An automation hidden in a backend tool may work, but a proper interface makes it easier to sell, use and support.
Interface Options
Use:
Google Form
Tally
Typeform
Airtable Interface
Google Sheet
WordPress page
Lovable web app
Supabase app
custom dashboard
client portal
Chrome extension
WhatsApp assistant
Telegram bot
voice agent
email interface
Brain Room style interface
native-style custom automation module
Interface Questions
Ask:
Does the user need to see the system?
Does the user need to input data?
Does the user need a dashboard?
Does the user need approval buttons?
Does the system need to look professional?
Is this for internal use only?
Is this a client demo?
Is this a paid product?
Does perceived value matter?
Does UX reduce support burden?
Will operators repeatedly configure the same API action?
Would a reusable custom module improve usability and reduce error?
Rule
Client-facing systems usually need a better interface than internal workflows.
Reusable integration components should provide clear labels, descriptions, allowed values and operator guidance.
- Database And State Layer
Database choice determines system reliability and intelligence.
Database Decision Questions
Ask:
Is data temporary or long term?
Does data need relationships?
Does data need search?
Does data need semantic retrieval?
Does data need user accounts?
Does data need permissions?
Does data need audit logs?
Does data need source tracking?
Does data need deletion?
Does data need dashboard reporting?
Is it sensitive?
Is it client-specific?
Is it product data?
Does the workflow produce intermediate values?
Must intermediate values survive between workflow branches?
Must state persist between separate workflow runs?
Does more than one workflow need access to the same state?
Database Selection Guide
Use Google Sheets when:
the system is simple
data volume is low
manual review is needed
the workflow is temporary
Use Airtable when:
visual data management matters
content or review workflows need status fields
non-technical users need visibility
a lightweight database is enough
Use Supabase when:
user authentication is needed
vector search is needed
app backend is needed
serious database structure is required
client data separation matters
future productization matters
persistent workflow state is required
Use WordPress database when:
the system lives inside a WordPress plugin
admin UI is tied to WordPress
MCR or Brain pages are involved
WordPress is the operational environment
Use vector database when:
semantic retrieval is needed
documents need to be searched by meaning
RAG is required
business memory is required
Workflow State Standard
Intermediate values should be stored explicitly when they are required later.
State may include:
calculations
classification results
record IDs
status values
API responses
approval decisions
cost totals
timestamps
aggregated outputs
progress markers
State should use:
clear names
defined scope
predictable type
documented source
documented downstream use
appropriate persistence
State Architecture Questions
Ask:
Can the value remain inside one step?
Does it need a named variable?
Does it need a structured object?
Does it need database persistence?
Does it need to be shared across branches?
Does it need to be passed to another workflow?
Does it need an audit history?
Is the platform making simple state management unnecessarily complex?
Rule
Do not use a spreadsheet as a production database unless the risk and scale are low.
Do not hide important workflow state inside unclear routers, aggregators or unnamed variables.
- AI Model And Prompt Layer
AI tools must match the task.
AI Decision Questions
Ask:
Does this task need AI?
Is AI generating content?
Is AI classifying data?
Is AI extracting fields?
Is AI answering from memory?
Is AI making recommendations?
Is AI using tools?
Does the output need JSON?
Does the output need human review?
Does the output need source references?
What model quality is required?
What model cost is acceptable?
AI Use Types
Use simple models for:
classification
short summaries
formatting
routing
simple extraction
Use stronger models for:
complex reasoning
client reports
strategy recommendations
sales diagnosis
legal or compliance-adjacent review
multi-source synthesis
Use structured outputs when:
data must enter a workflow
JSON is required
fields must be clean
API payloads must be valid
automation cannot tolerate messy text
Use human review when:
the output affects clients
the output affects sales
the output affects compliance
the output affects public content
the output affects reputation
Rule
AI output must be structured when automation depends on it.
- Hosting And Infrastructure Layer
Hosting choice affects uptime, privacy, cost and maintenance.
Hosting Options
Use:
local computer
VPS
RackNerd
managed n8n cloud
Make cloud
Supabase cloud
WordPress hosting
client-owned hosting
cloud app hosting
hybrid local and cloud
Hosting Questions
Ask:
Does this need to run all day?
Can it stop when the computer is off?
Is this client-facing?
Is uptime important?
Is privacy important?
Is cost important?
Who maintains it?
Who has access?
Who backs it up?
What happens if it fails?
Does M need to support it?
Does the client require local control?
Where do reusable connectors or modules live?
Who owns their release and maintenance?
Rule
Local hosting is not automatically better. Cloud hosting is not automatically safer. Choose based on risk, uptime, privacy and maintenance.
- Security And Compliance Layer
Every architecture decision must include risk review.
Security Questions
Ask:
What credentials are used?
Where are API keys stored?
Is a service role key involved?
Is a webhook exposed?
Is authentication required?
Is user data stored?
Is client data stored?
Is browser automation logging in?
Is scraping involved?
Are platform terms affected?
Is personal data processed?
Is sensitive data processed?
Is human review required?
Is deletion possible?
Is access revocation possible?
Does the custom connector expose credentials?
Can fixed values be altered by operators?
Can a public connector be misused?
Does one workflow trigger another without validation?
Risk Areas
Review:
webhook exposure
API key leakage
browser session leakage
account ban risk
client data mixing
unapproved data collection
insecure frontend secrets
unsafe Supabase permissions
local machine vulnerability
MCP tool misuse
AI hallucination
direct autoposting
automated outreach
voice agent disclosure
customer privacy
custom connector publication
unsafe default values
unvalidated mapped parameters
cross-workflow data leakage
duplicate scenario triggers
Rule
Architecture is not approved until security and compliance risks are visible.
- Cost And Maintenance Layer
A system must be affordable and maintainable.
Cost Sources
Costs may include:
n8n hosting
Make operations
Supabase usage
OpenAI or Claude tokens
voice agent minutes
browser automation compute
storage
email sending
SMS
API calls
image generation
video generation
developer time
support time
client onboarding
debugging time
tool subscriptions
custom connector maintenance
API version changes
workflow retry costs
Maintenance Questions
Ask:
Who fixes it?
How often will it break?
How easy is debugging?
Are logs available?
Are errors visible?
Are retries controlled?
Are costs monitored?
Is there a fallback?
Does it need documentation?
Can the client support it?
Can MWMS support it?
Is M required?
Who maintains custom modules and connectors?
What happens when the external API changes?
Can one connector update replace changes across many workflows?
Rule
A system that is cheap to build but expensive to support is not cheap.
A reusable connector is valuable only when the reduction in repeated work exceeds its maintenance cost.
- Scale And Upgrade Layer
Not every prototype should become production.
Scale Questions
Ask:
Is the workflow proven manually?
Has the prototype worked with real data?
Has a user tested it?
Has it generated value?
Is usage predictable?
Is cost per run known?
Is failure rate acceptable?
Are security controls strong enough?
Is the interface usable?
Is the backend strong enough?
Should this be rebuilt properly?
Should this stay as a no-code system?
Should this become a product?
Should repeated HTTP calls become a reusable connector?
Should one large workflow become several sub-workflows?
Should workflow state move into a persistent database?
Upgrade Paths
A system may move from:
manual workflow to Google Sheet
Google Sheet to Airtable
Airtable to Supabase
Make to n8n
raw HTTP request to reusable custom module
single scenario to modular sub-workflows
temporary variables to persistent state
prototype to WordPress plugin
Lovable MVP to custom app
single workflow to productized AIOS module
internal tool to micro SaaS
simple automation to client operating system
Rule
Prototype quickly, but do not pretend prototypes are production systems.
Architecture Decision Scorecard
Before choosing architecture, score the system out of 100.
Score Categories
Business Outcome Clarity: 10
User Fit: 10
Data Source Clarity: 10
Workflow Complexity Fit: 10
Tool Fit: 10
Interface Need: 10
Database And State Fit: 10
Security And Compliance Fit: 10
Cost And Maintenance Fit: 10
Scale Path Clarity: 10
Interpretation
85–100: Architecture is strong and ready to proceed
70–84: Good architecture with minor risks to resolve
55–69: Prototype only or needs redesign before production
40–54: Too risky or unclear
Below 40: Do not build yet
Rule
A system should not move to production unless the architecture score is strong.
MWMS Tool Selection Matrix
Use Make When
Use Make when:
speed matters
workflow is simple
integration is straightforward
a visual demo helps
client understands the platform
low technical depth is needed
fast testing is more important than deep control
a repeated API action can be simplified through a governed custom module
Avoid Make when:
workflow is highly complex
user access control is needed
advanced database logic is required
long-term MWMS infrastructure is needed
heavy AI agent logic is required
state handling requires excessive routers and aggregators
the scenario is becoming difficult to explain or maintain
Use n8n When
Use n8n when:
workflow complexity is higher
API logic matters
AI agents are involved
reusable internal systems are needed
self-hosting matters
MWMS wants more control
custom error handling is needed
systems must connect across many Brains
sub-workflows and structured modularity matter
Avoid n8n when:
a simple form-to-email will do
user interface is the main need
client cannot support it
M’s development work would be disrupted
Use Lovable When
Use Lovable when:
a fast frontend is needed
a demo must look good
client perception matters
an MVP needs to be tested
a micro SaaS idea needs quick validation
dashboards or portals are useful
Avoid Lovable when:
production reliability is required immediately
complex security is required
user data is sensitive and not reviewed
the system needs long-term custom architecture
no one will test or maintain the app
Use Claude Code When
Use Claude Code when:
no-code is too limited
custom logic is required
file-based development is needed
a real codebase must be created
GitHub versioning matters
M or a developer can review and maintain it
a reusable connector needs stronger control than a visual custom module provides
Avoid Claude Code when:
the workflow can be done safely in no-code
no one can review the code
the task is vague
the system is not worth technical debt
Use Supabase When
Use Supabase when:
authentication is needed
app backend is needed
vector storage is needed
structured records matter
user access matters
chat history matters
source retention matters
productization is likely
persistent workflow state matters
Avoid Supabase when:
simple spreadsheet storage is enough
no one understands the schema
security settings are unclear
service role keys would be exposed
Use Airtable When
Use Airtable when:
visibility matters
operators need a simple table interface
status workflows matter
content or asset management is needed
early client systems need structure
Avoid Airtable when:
sensitive data needs tighter control
high-scale backend logic is required
authentication and permissions are complex
Use Google Sheets When
Use Google Sheets when:
the system is early
data is simple
manual review matters
speed and cost matter
prototype logging is enough
Avoid Google Sheets when:
the data is sensitive
records are complex
access control matters
production reliability matters
Use Raw HTTP When
Use raw HTTP when:
the API is being tested
only one workflow needs the endpoint
the integration is temporary
request and response behaviour is still being learned
speed of proof matters
Avoid repeated raw HTTP when:
the same authentication and payload are copied repeatedly
operators must manually rebuild the same request
input validation matters
the integration is becoming permanent
multiple clients or systems will use it
Use Reusable Custom Connectors When
Use reusable custom connectors when:
the API action is proven
the same action is repeated
standard fields are known
fixed and dynamic parameters can be separated
allowed values can be constrained
operator usability matters
errors from manual configuration are likely
multiple workflows or clients will benefit
Avoid custom connectors when:
the API is still unstable
the use case is one-off
there is no maintenance owner
publication creates more support burden than value
Use Browser Automation When
Use browser automation when:
no API exists
the task is browser-based
form filling is required
visual navigation matters
a controlled workflow can be tested
terms and risk are reviewed
Avoid browser automation when:
direct API exists
platform terms prohibit automation
login credentials are sensitive
accounts may be banned
the workflow is mission-critical
high reliability is required
Use MCP When
Use MCP when:
flexible AI tool access is useful
the task is exploratory
tools need to be discovered dynamically
operator supervision exists
security boundaries are clear
Avoid MCP when:
deterministic output is required
production reliability matters
tool misuse would be costly
strict compliance is required
a simple workflow would be safer
Use Direct API When
Use direct API when:
platform supports it
production reliability matters
data exchange must be predictable
workflow must scale
logging matters
security can be controlled
Avoid direct API when:
API access is not available
setup cost outweighs value
the workflow is temporary
manual export is enough
No Code Versus Code Decision Standard
Use No Code When
Use no-code when:
speed matters
workflow is simple to medium
changes are frequent
visual maintainability matters
client needs visibility
prototype stage is active
business value is not yet proven
Use Code When
Use code when:
reliability matters
security matters
scale matters
user access matters
custom logic matters
no-code becomes fragile
system is productized
system becomes client-facing and mission-critical
data model is complex
state handling becomes difficult in no-code
reusable connector maintenance requires version control and testing
Use Hybrid When
Use hybrid when:
no-code handles orchestration
code handles custom logic
Supabase handles data and persistent state
Lovable handles interface
WordPress handles operational admin
custom connectors simplify repeated API actions
AI handles drafting or reasoning
humans handle approval and governance
Rule
MWMS should not be ideological about no-code or code. The correct answer is the architecture that fits the job.
Raw HTTP Versus Reusable Connector Decision Standard
Use Raw HTTP When
Use raw HTTP when:
testing an API
proving one endpoint
building a temporary prototype
using the action only once
learning the payload and response
Use A Reusable Connector When
Use a reusable connector when:
the action is repeated
the payload structure is stable
more than one operator will use it
input validation matters
operator-facing labels improve usability
client delivery needs standardisation
authentication should be centralised
support and maintenance savings are likely
Connector Requirements
Every reusable connector should define:
connector owner
external API owner
authentication method
base URL
allowed endpoints
allowed methods
fixed parameters
mappable parameters
required inputs
allowed values
default values
output fields
error responses
retry behaviour
test cases
version
publication level
maintenance process
Rule
Do not convert every HTTP request into a custom connector. Standardise only when repeat use and reliability justify the maintenance burden.
Workflow Modularity Standard
Large workflows should be separated when modularity improves reliability, reuse or maintenance.
Split A Workflow When
Split when:
a function is reused
a section has a different owner
a section requires different permissions
a section has an independent failure path
a section needs separate testing
a section runs on a different schedule
the main workflow has become difficult to understand
a specialised function should be centrally maintained
Keep A Workflow Together When
Keep together when:
steps are tightly linked
splitting creates unnecessary latency
the workflow is short
data passing would create more risk than value
debugging is easier in one flow
no reuse exists
Cross-Workflow Trigger Requirements
When one workflow triggers another, define:
trigger method
authentication
payload schema
required fields
source workflow
destination workflow
duplicate prevention
timeout behaviour
retry rules
error response
logging
correlation ID
cost impact
Rule
Modularity should reduce complexity, not distribute confusion across more workflows.
Workflow State And Variable Standard
When intermediate results are needed later, store them explicitly.
Use:
clear variable names
defined data types
structured objects where appropriate
documented scope
consistent formatting
controlled aggregation
persistent storage when needed
Avoid:
unnamed values
ambiguous branches
repeated calculations
hidden dependencies
excessive router workarounds
flattening structured data too early
State Decision
Use temporary workflow variables when:
the value is needed only during one run
the value is low risk
the value does not need history
Use persistent storage when:
the value is needed across runs
the value must be audited
multiple workflows need it
the workflow can pause and resume
the value affects a client or customer
Rule
If simple state management becomes excessively complicated in the chosen platform, reassess the architecture instead of adding endless workarounds.
Prototype Versus Production Standard
Prototype System
A prototype may use:
Google Sheets
Airtable
Make
Lovable
raw HTTP calls
manual approvals
test data
limited users
temporary credentials
low-risk workflows
Prototype goal:
prove value
test user behaviour
validate workflow
understand data requirements
find failure points
Production System
A production system should include:
secure credentials
access control
stable database
logging
error handling
backups
documentation
human review where needed
usage monitoring
cost monitoring
support plan
compliance review
clear owner
standardised connectors where repeat use justifies them
controlled workflow state
Rule
Prototype tools are allowed, but production claims require production discipline.
Client Facing Versus Internal Tool Standard
Internal Tool
Internal tools can be rougher if:
only MWMS uses them
data risk is low
outputs are reviewed
manual correction is acceptable
failure does not harm clients
Client Facing Tool
Client-facing tools need:
better interface
stronger reliability
clearer onboarding
stronger permissions
support path
error handling
documentation
privacy review
cost review
rollback plan
standardised integrations
tested inputs and outputs
Rule
Never treat a client-facing system like an internal experiment.
Dashboard First Architecture Rule
When selling AIBS systems, dashboards often increase perceived and actual value.
A dashboard helps show:
baseline
improvement
activity
bottlenecks
lead flow
review flow
sales progress
customer issues
automation output
ROI signals
Dashboard Questions
Ask:
What number matters?
What baseline exists?
What should improve?
What does the client need to see?
What does MWMS need to monitor?
What actions should follow from the dashboard?
What proves value?
Rule
For client systems, if value is measurable, dashboard visibility should be considered early.
Human Strategy Layer
The tool stack is not the whole system.
MWMS architecture must include human strategy.
Human Strategy Questions
Ask:
What decision does this system support?
What human action follows the automation?
Who approves important outputs?
Who responds to exceptions?
Who owns improvements?
Who reviews reports?
Who handles unhappy customers?
Who updates the system?
Who decides whether to scale?
Who maintains reusable connectors?
Who decides when a workflow should be split or rebuilt?
Rule
Automation without human strategy becomes brittle and disconnected from business value.
Architecture Drift Protection
This framework protects MWMS from:
chasing shiny tools
using n8n for everything
using Make for everything
using Lovable for everything
using Claude Code too early
using no-code when code is required
using code when no-code is enough
using browser automation when an API exists
using MCP when schema is safer
repeating raw HTTP requests across workflows
creating reusable connectors too early
building oversized scenarios
splitting workflows without clear purpose
hiding state inside confusing routers
building client-facing prototypes with no support plan
letting tool demonstrations become business strategy
creating systems M cannot maintain
ignoring data structure
ignoring cost per run
ignoring access control
ignoring client privacy
ignoring dashboard visibility
confusing impressive workflows with valuable outcomes
Architecture Drift Signals
Watch for:
“This tool is hot right now.”
“Everyone is using this.”
“Let’s use it because the course used it.”
“We can build the whole thing in one prompt.”
“No need to map the workflow first.”
“We can fix security later.”
“Let’s scrape it.”
“Use browser automation instead of checking for an API.”
“Copy the HTTP module into every workflow.”
“Let’s create a custom connector before testing the API.”
“Split it into separate scenarios because we can.”
“We can store the values somewhere later.”
“M can clean it up later.”
“The client will not care how it works.”
“The demo worked once, so it is ready.”
“Let’s skip the dashboard.”
“Let’s go straight to production.”
“We do not need human review.”
Rule
When these drift signals appear, stop and apply the Architecture Decision Scorecard.
MWMS Architecture Selection Workflow
Use this workflow before starting a build.
Step 1: Define The Business Outcome
Write:
problem
user
desired result
success metric
risk level
Step 2: Map The Workflow
Write:
trigger
input
data source
process
AI step
intermediate state
output
storage
approval
delivery
reporting
Step 3: Identify Risk
Review:
privacy
compliance
security
tool access
credentials
client data
platform terms
hallucination
user harm
cost
Step 4: Choose Tool Stack
Choose:
automation engine
database
interface
AI model
hosting
reporting layer
approval layer
integration method
state handling method
Step 5: Decide Integration Pattern
Choose:
native module
raw HTTP
reusable connector
webhook
sub-workflow
direct API
browser automation
MCP
Step 6: Decide Prototype Or Production
Decide:
manual first
prototype
internal tool
client pilot
production system
productized offer
Step 7: Define Maintenance
Define:
owner
support path
logs
error handling
documentation
change control
connector maintenance
workflow versioning
upgrade path
Step 8: Score The Architecture
Use the scorecard before build.
Rule
Architecture must be written before implementation.
Example Architecture Decisions
Example 1: Simple Lead Form To Email
Best architecture:
Tally or WordPress form
Make or n8n
Gmail or CRM
Google Sheet log
Do not use:
full Supabase app
Lovable portal
Claude Code build
MCP
custom connector
Reason:
The workflow is simple.
Example 2: AIBS Client Diagnostic Report
Best architecture:
structured intake form
Supabase or Airtable
AI report generation
human review
PDF or dashboard output
CRM follow-up
Possible tools:
n8n
Supabase
Airtable
OpenAI or Claude
WordPress or Lovable frontend
Reason:
This requires structured data, AI synthesis, review and sales follow-up.
Example 3: Local Review Automation
Best architecture:
customer completion trigger
SMS or email system
feedback form
routing logic
dashboard
manager alerts
Possible tools:
Make or n8n
Airtable or Supabase
Twilio or email tool
dashboard interface
Reason:
The workflow is commercial, measurable and client-facing.
Example 4: Client Knowledge Base Chatbot
Best architecture:
approved document intake
embeddings
vector storage
retrieval
source tracking
chat interface
deletion process
Possible tools:
Supabase vector
n8n
OpenAI or Claude
WordPress or Lovable frontend
Reason:
This requires memory, retrieval, source freshness and privacy controls.
Example 5: Browser Form Filling
Best architecture:
direct API if available
browser automation only if API unavailable
limited session
risk review
logging
human verification
Possible tools:
Airtop
Axiom
n8n
manual review
Reason:
Browser automation is powerful but risky.
Example 6: Micro SaaS Tool
Best architecture:
frontend
authentication
payment
access control
backend workflow
database
usage limits
support path
Possible tools:
Lovable prototype
Supabase backend
Stripe
n8n
custom code later
Reason:
Paid products need access control, cost control and user management.
Example 7: Repeated Image Generation API Calls
Early Prototype Architecture:
Make
raw HTTP request
manual payload fields
response inspection
Production Or Repeated-Use Upgrade:
reusable custom module
centralised API connection
validated input fields
fixed and mappable parameters
standardised output
version owner
Reason:
Raw HTTP is appropriate for proving the API. A reusable connector becomes appropriate when the same operation is repeated and operator reliability matters.
Example 8: One Workflow Triggering Another
Best architecture:
protected webhook or native sub-workflow call
structured payload
required fields
correlation ID
duplicate protection
error response
execution logging
Reason:
Sub-workflows can improve reuse and failure isolation, but only when the connection between workflows is governed and observable.
Example 9: Multiple Intermediate Calculations
Best architecture:
named variables or structured object
clear data types
single aggregation point
explicit formatting
persistent storage only if needed across runs
Architecture Reassessment Trigger:
If the platform requires excessive routers, aggregators and workarounds for simple state, consider n8n, a code step or persistent database state.
Reason:
Workflow state should remain understandable and maintainable.
Application To Automation Brain
Automation Brain owns this framework.
Automation Brain should use it to:
choose correct automation platforms
avoid tool drift
define workflow architecture
protect maintainability
document build decisions
prevent fragile systems
decide no-code versus code
decide API versus browser automation
decide raw HTTP versus reusable connector
decide single workflow versus sub-workflows
define workflow state
decide prototype versus production
Automation Brain Rule
Automation Brain must solve workflow problems, not collect tools.
Application To HeadOffice Brain
HeadOffice Brain should use this framework to approve major architecture choices.
HeadOffice should ask:
Does this support MWMS strategy?
Is this the right tool?
Does this create unnecessary cost?
Does this burden M?
Does this improve client value?
Does this create risk?
Does this need a dashboard?
Should this be manual first?
Should this become a product?
Should repeated integration work be standardised?
HeadOffice Rule
HeadOffice approves architecture based on strategic value, not technical excitement.
Application To AIBS Brain
AIBS Brain should use this framework before recommending client systems.
AIBS should ask:
What is the client problem?
What is the business outcome?
What architecture fits the client?
What does the client need to see?
What can be supported?
What can be measured?
What creates the first win?
What should not be automated?
Will this integration be reused across several clients?
AIBS Rule
AIBS architecture must follow business diagnosis.
Application To Product Brain
Product Brain should use this framework when deciding whether an automation becomes a product.
Product Brain should ask:
Does this need a frontend?
Does this need authentication?
Does this need payment?
Does this need usage limits?
Does this need proper backend?
Does this need prototype testing?
Does this need custom code?
Does this need a standardised connector layer?
Product Brain Rule
Product architecture must be stronger than demo architecture.
Application To Data Brain
Data Brain should use this framework to choose storage, schema, state and retrieval systems.
Data Brain should decide:
spreadsheet
Airtable
Supabase
vector storage
WordPress database
temporary memory
long-term memory
workflow state
audit logs
source metadata
Data Brain Rule
Data architecture must match the future value and risk of the data.
Application To Compliance And Risk Brain
Compliance and Risk Brain should review tool architecture when systems involve:
client data
customer data
browser automation
scraping
MCP
API keys
custom connectors
public modules
webhook chaining
Supabase service roles
local hosting
voice agents
outreach
review automation
public posting
paid products
Compliance Rule
Risk review is part of architecture, not an afterthought.
Application To Finance Brain
Finance Brain should review architecture for cost.
Finance Brain should track:
tool subscriptions
AI token cost
browser automation compute
voice minute cost
hosting cost
storage cost
support cost
cost per run
connector maintenance cost
retry cost
margin impact
product profitability
Finance Rule
Tool choice must be economically sustainable.
Deferred Update And Parking Lot Section
This page creates later update needs.
Later Update 1: MWMS AI Automation Security And Risk Checklist
Add:
tool selection risk review
browser automation risk
MCP risk
local hosting risk
Supabase service role key caution
direct API versus browser automation decision
custom connector credential handling
public connector publication risk
webhook chaining risk
duplicate execution prevention
cross-workflow data leakage
prototype versus production security checklist
Later Update 2: MWMS AI Usage And Cost Visibility Standard
Add:
tool stack cost mapping
cost per workflow run
cost per AI call
browser automation compute cost
voice agent minute cost
Lovable prototype cost
Make versus n8n operation cost
custom connector maintenance cost
cross-workflow retry cost
production cost review
Later Update 3: MWMS Productized AIOS Service Packaging And Scope Control Framework
Add:
architecture selection before packaging
prototype stack versus production stack
client-facing interface requirements
dashboard-first value display
tool support boundaries
reusable connector support boundaries
no-code versus code scope boundary
Later Update 4: MWMS Micro SaaS Productization And Access Control Framework
Add:
tool selection before micro SaaS approval
Lovable MVP to production migration
Supabase backend fit
Stripe and access control architecture
connector versioning
workflow state persistence
prototype kill or upgrade decision
Later Update 5: MWMS Client Intelligence And Business Memory Automation Framework
Add:
architecture selection for memory systems
Supabase versus Airtable versus vector storage
RAG tool decision pathway
local versus cloud memory hosting
persistent state design
source security review
Later Update 6: MWMS AI Tool Access Browser Automation And MCP Governance Framework
Add:
custom API module governance
connector authentication
endpoint permission boundaries
fixed versus mappable parameters
required input validation
allowed value constraints
webhook-to-webhook triggers
duplicate execution protection
request and response inspection
public connector publication boundaries
tool action logging
Later Update 7: MWMS AI App Builder And Productized Interface Framework
Add:
Lovable as interface prototype
Claude Code as upgrade path
Supabase as app backend
GitHub as code control
client-facing prototype rules
custom connector layer
when to rebuild properly
Later Update 8: MWMS AIBS Business Diagnostic And Opportunity Discovery Framework
Add:
architecture recommendation section
audit-to-architecture pathway
business problem to tool stack mapping
reusable integration opportunity
dashboard-first system recommendation
Future AI Employee Ideas
These AI Employee ideas are parked candidates only.
Automation Architecture Advisor
Primary Brain: Automation Brain / HeadOffice Brain
Status: Parked Candidate
Purpose: Chooses the best tool stack for each MWMS or client system based on outcome, complexity, risk, cost and maintainability.
No Code Versus Code Analyst
Primary Brain: Automation Brain
Status: Parked Candidate
Purpose: Decides whether a workflow should remain no-code, move to custom code or use a hybrid approach.
Tool Stack Risk Reviewer
Primary Brain: Compliance Brain / Risk Brain
Status: Parked Candidate
Purpose: Reviews automation architecture for security, platform, credential, privacy and reliability risks.
Prototype To Production Advisor
Primary Brain: Product Brain / Automation Brain
Status: Parked Candidate
Purpose: Decides when a Lovable, Make, Airtable or Google Sheet prototype should remain as is, be improved or be rebuilt properly.
Automation Cost Analyst
Primary Brain: Finance Brain
Status: Parked Candidate
Purpose: Calculates tool costs, AI token costs, hosting costs, usage costs and support costs for automation systems.
Client System Interface Strategist
Primary Brain: UX Brain / Product Brain
Status: Parked Candidate
Purpose: Decides when client systems need dashboards, portals, forms, app interfaces or simple backend workflows.
Data Architecture Mapper
Primary Brain: Data Brain
Status: Parked Candidate
Purpose: Chooses between Google Sheets, Airtable, Supabase, WordPress database, vector storage and custom database architecture.
Hosting Decision Advisor
Primary Brain: Automation Brain / Risk Brain
Status: Parked Candidate
Purpose: Decides between local hosting, VPS hosting, managed cloud tools, client-owned infrastructure and hybrid hosting.
Integration Component Architect
Primary Brain: Automation Brain
Status: Parked Candidate
Purpose: Identifies repeated API operations and converts them into reusable, validated integration components when standardisation is justified.
Workflow Modularity Analyst
Primary Brain: Automation Brain
Status: Parked Candidate
Purpose: Identifies workflows that should remain together, be divided into reusable sub-workflows or be rebuilt using a different architecture.
Workflow State Designer
Primary Brain: Automation Brain / Data Brain
Status: Parked Candidate
Purpose: Defines how intermediate values, calculations, status and cross-workflow state should be named, stored, reused and audited.
Drift Protection
This framework protects MWMS from:
tool hype
automation spaghetti
unclear ownership
fragile demos
overbuilt prototypes
underbuilt production systems
unnecessary Claude Code use
unnecessary Lovable apps
unnecessary browser automation
ungoverned MCP usage
repeated raw HTTP configuration
premature custom connector development
uncontrolled connector publication
oversized workflows
unnecessary sub-workflow fragmentation
hidden state dependencies
weak database decisions
spreadsheet overuse
client-facing systems with no support plan
ignoring dashboard value
ignoring cost
ignoring security
dumping maintenance onto M
confusing “can build” with “should build”
Strategic Summary
The AI Native Entrepreneur Architecture And Tool Decision Block and Make Workflow Modularity Block showed many tools and build paths.
The important MWMS lesson is not that one tool wins.
The important lesson is that every tool and integration pattern has a role.
n8n, Make, Claude Code, Lovable, Supabase, Airtable, Google Sheets, browser automation, MCP, direct APIs, raw HTTP requests, reusable connectors, local hosting and cloud hosting can all be useful.
But they are useful only when matched to the correct problem.
Raw HTTP is useful for proving an API.
Reusable connectors are useful when an API operation becomes repeated, stable and operator-facing.
Single workflows are useful when the process is simple and tightly connected.
Sub-workflows are useful when modularity improves reuse, testing, ownership or failure isolation.
Temporary variables are useful within one execution.
Persistent state is required when information must survive across runs, workflows or users.
The strategic upgrade for MWMS is:
Build the right architecture for the business outcome, then standardise only the parts that have earned repeat use.
This framework gives MWMS a disciplined method for choosing tools, avoiding bloat, protecting M’s development time, supporting AIBS client delivery and preventing shallow AI automation thinking.
MWMS should not be known for building automations.
MWMS should be known for diagnosing business problems and building the right AI operating systems to solve them.
Final Standard
The MWMS final standard is:
No MWMS automation, AIOS system, client workflow, productized tool, reusable connector or internal build should begin until the business outcome, user, data source, workflow complexity, tool fit, interface need, database and state need, AI role, integration pattern, hosting model, security risk, cost, maintenance owner and scale path have been considered.
A valid MWMS automation architecture decision must define:
business problem
desired outcome
user
operator
data source
workflow steps
workflow state
automation engine
integration method
raw HTTP or reusable connector decision
single workflow or sub-workflow decision
interface
database
AI model
hosting
security risks
compliance risks
cost drivers
maintenance owner
logging
human review points
prototype or production status
upgrade path
That is the MWMS Automation Architecture And Tool Selection standard.
Change Log
Version: v1.1
Date: 2026-06-14
Author: HeadOffice
Change:
Updated the MWMS Automation Architecture And Tool Selection Framework using the AI Automations by Jack Make Workflow Modularity Block.
Added durable architecture principles covering:
raw HTTP request versus reusable connector decisions
custom Make modules as reusable integration components
centralised API authentication
static versus mappable parameters
required input validation
allowed value constraints
operator-friendly connector labels and help text
request and response inspection
reusable integration maintenance
single workflow versus sub-workflow decisions
webhook-based cross-workflow triggers
structured payload passing
duplicate execution prevention
correlation and logging
temporary versus persistent workflow state
named variables
intermediate calculations
aggregation
platform complexity as an architecture reassessment signal
Updated the Automation Architecture Decision Model by strengthening:
Workflow Complexity Layer
Tool Fit Layer
Interface Layer
Database And State Layer
Security And Compliance Layer
Cost And Maintenance Layer
Scale And Upgrade Layer
Added new operating sections:
Raw HTTP Versus Reusable Connector Decision Standard
Workflow Modularity Standard
Workflow State And Variable Standard
Use Raw HTTP guidance
Use Reusable Custom Connectors guidance
Example Architecture Decision for repeated API calls
Example Architecture Decision for workflow chaining
Example Architecture Decision for intermediate calculations
Added future AI Employee candidates:
Integration Component Architect
Workflow Modularity Analyst
Workflow State Designer
Change Impact Declaration
Pages Created:
None
Pages Updated:
MWMS Automation Architecture And Tool Selection Framework
Pages Deprecated:
None
Standalone Pages Not Created:
Create Custom Make Modules Framework
Webhook Scenario Chaining Framework
Workflow Variable And Aggregation Framework
Make Custom App Framework
Registries Requiring Update:
Automation Brain Page Registry
MWMS Course Absorption Decision Registry after all agreed page updates are completed
Canon Version Update Required:
No
Change Log Entry Required:
Yes
Strategic Absorption Result:
MWMS now has a stronger architecture standard for deciding when to prototype with raw HTTP, when to create reusable integration components, when to divide large workflows into controlled sub-workflows and when intermediate state requires explicit variables or persistent storage. The update absorbs the durable system-design value from the Make tutorials without adding platform-specific implementation bloat to MCR.
END — MWMS AUTOMATION ARCHITECTURE AND TOOL SELECTION FRAMEWORK v1.1