Make announced a dedicated Mentorship Office at STATION F in Paris to help startups identify automation opportunities, build initial scenarios, learn the platform through workshops and onboarding, and connect through campus events. The announcement describes a support initiative, not a documented prebuilt automation product or a guaranteed number of sessions for every founder.
This distinction matters for planning. A founder can bring a manual process, map its trigger and destination with a mentor, and decide whether a rules-based Make scenario is appropriate. That is a proposed way to use process-discovery support. It is not evidence that Make has built a STATION F workflow, campus data connection, CRM integration or public intake system.
This article explains what the partnership establishes, what remains unspecified, and how to prepare a safe first automation without assuming access to STATION F systems or automatic entry to Make’s separate Startup Program.
What the Make-STATION F partnership means for startups
In its April 16, 2026 announcement, Make said it was joining STATION F with a dedicated Mentorship Office. The planned support includes one-to-one mentorship to identify automation opportunities and build initial scenarios, workshops and onboarding for different levels of use, and participation in campus events such as hackathons and networking meetups. Make’s announcement describes the intended activities, but it is not an operating manual.
STATION F’s partnership guidance describes a Mentorship Office as an on-campus partnership category, and its institutional FAQ lists Make among organizations with mentorship offices. Those pages do not specify Make’s office hours, staffing, booking process, eligibility rules, service levels or a technical connection to STATION F systems. Ask Make or STATION F directly about current access and arrangements before planning around a session.
The partnership is also separate from Make’s Startup Program. Make’s current program page says qualifying startups may apply under published conditions. The partnership announcement does not establish automatic enrollment or benefits for every STATION F company. Review the current Startup Program terms separately.
Treat the Mentorship Office as a process-discovery channel. Bring a repeatable business problem, its current systems and a named owner, but do not assume the office supplies an integration, API or universal booking entitlement.
How to read STATION F’s changing scale figures
Numbers associated with STATION F describe different grains. Make’s April 2026 announcement reported more than 1,000 startups hosted at a time and more than 8,000 supported since 2017. STATION F’s homepage, retrieved in October 2026, reports 1,000+ startups on campus and 9,000 startups. These should not be combined as though they were one current population.
The safest interpretation is that the first type of figure describes a current campus population, while the second describes a cumulative group associated with or supported by the campus. The pages do not fully define every counting method. When repeating a figure, preserve the publisher, date and measure rather than trying to reconcile the totals.
Current campus figure: STATION F’s October 2026 homepage says 1,000+ startups on campus. Cumulative figure: the same page says 9,000 startups, while Make reported more than 8,000 supported since 2017 in April 2026. Attribute each number to its source and date.
STATION F describes itself as the world’s largest startup campus. That is an institutional description, not an independently audited ranking. Its official pages also report roughly 30 or more programs, just over 600 annual events and 700+ investors on the current homepage. These figures provide ecosystem context, not proof of the Mentorship Office’s capacity.
What the Mentorship Office says it will do, and what remains unspecified
Make’s announcement gives founders a useful high-level expectation: the office is intended to help teams identify repetitive work, connect existing tools, build initial scenarios, understand operations and engage with the wider campus community. It does not promise that every founder receives one-to-one support, a particular workshop, a fixed number of sessions or a production-ready workflow.
Make also reported that more than 200 STATION F startups had already joined its existing Startup Program. That number comes from the announcement and is not confirmed by a current public roster in the sources reviewed. It should not be treated as evidence that all campus startups qualify for the program.
Before relying on a benefit, confirm four practical points with the relevant contact: who can access the office, how a session is requested, what type of support is currently available, and whether any program eligibility or data restrictions apply. Separately verify each connector, permission and destination needed for an automation.
Turn a mentorship conversation into a usable automation brief
Start with an operational problem rather than a preferred AI tool. Describe the recurring task, accountable owner, trigger, source application, destination system, frequency, failure cost, data involved and observable definition of completion. The process owner should approve the description and data boundaries before anyone enables writes.
The following is an editorial implementation proposal, not an official Make or STATION F intake form:
{
"process_name": "Illustrative: inbound demo request handling",
"business_owner": "Operations lead",
"trigger_type": "Form submission, if supported by the source",
"source_application": "Founder-verified form system",
"destination_application": "Approved CRM",
"repetitive_steps": [
"Check required fields",
"Find or create a request record"
],
"pii_present": true,
"success_measure": "Valid requests reach the CRM or an exception queue"
}A good brief is useful even when the conclusion is not to automate. It should expose an unsupported connector, an unclear owner, sensitive data or an unacceptable failure consequence before those issues become production incidents.
Choose rules or AI for the job the process needs
Make distinguishes standard scenarios, which follow defined rules, from AI and AI-agent scenarios, where AI can interpret information or choose among tools and paths. For required-field checks, allowlisted values, eligibility thresholds, routing and duplicate detection, explicit rules are generally easier to test and explain. AI is more appropriate when ambiguous text needs bounded interpretation.
Predictable decisions
Use rules for required fields, email-format checks, allowlisted applications, known request types, thresholds, permissions and duplicate event detection. The result can proceed to a verified destination or an explicit exception queue.
Ambiguous language
Use AI to extract candidate steps, group similar descriptions or suggest a category. Return structured fields, confidence and a review flag. Do not let an uncertain interpretation grant access, send a message or change a consequential record by default.
The examples below are proposed architectures based on documented Make capabilities. They are not Make-STATION F templates or campus integrations. Confirm the relevant source, connector, permission and destination for the startup’s own systems.
Example 1: Workshop notes to a reviewed process brief
- Trigger and input: A founder or mentor submits approved workshop notes or a process description through a founder-selected intake method. The input includes the process name, owner, current source, desired destination and any known sensitive data.
- Illustrative sequence: Receive the notes, pass free text to an AI step only when interpretation is needed, validate required fields and allowed application names with fixed rules, then send a proposed brief to a founder-selected backlog or project system for review.
- AI output: Return
process_name,trigger_candidate,source_application,destination_application,repetitive_steps,confidenceandhuman_review_required. The AI does not select the system of record, grant access or contact anyone. - Validation and destination: Reject missing destinations, unsupported applications, low confidence and notes containing sensitive data that has not been approved for processing. A process owner approves the brief before it is written to the backlog.
- Exception owner: The named process owner or mentor completes missing information and decides whether the proposal should be discarded, revised or investigated manually.
Make documents module tools, scenarios and MCP tools for AI agents, and its scenario guidance describes defined inputs and outputs for scenarios used as tools. Some help pages carry a previous-version notice, so check current product names and setup instructions before implementation. Make’s AI-agent tool guidance supports the capability distinction, not this STATION F use case.
Example 2: Form event to an approved system of record
- Trigger and input: A form system controlled by the startup sends an event to a Make custom webhook if the source supports the required connection and the startup has permission to configure it. The payload should contain a stable source event ID, timestamp, schema version, required fields and request type.
- Illustrative sequence: Receive the webhook, validate the event ID and schema, check required fields and allowlisted request types, then perform a duplicate-safe create or update in the approved CRM. Route rejected events and failed writes to a named exception queue.
- AI decision: Use no AI for required fields, email-format checks, known request types or duplicate detection. If free text needs classification, store the classification as a suggestion with
review_requiredrather than directly changing a consequential CRM field. - Validation and destination: Enforce uniqueness on
source_system + source_event_idwith a database constraint or a transactional upsert where the destination supports it. A lookup followed by a create is not sufficient when concurrent executions can process the same event. - Failure handling: Quarantine missing or invalid payloads. If the CRM rate-limits a write or the downstream response is uncertain, retain the event and assign it to the CRM owner. Do not silently discard it or blindly replay a non-idempotent create.
Make documents custom webhooks and retry and incomplete-execution behavior, but no STATION F webhook, API, export or dedicated campus connector was verified. Measure completion rate, exception rate, duplicate-write rate and manual handling time against a baseline rather than promising a particular improvement.
Build replay safety, ownership and a clear exception path
A retry is not an idempotency guarantee. Make’s Retry error handler can preserve failed bundle data and retry incomplete executions, while automatic retry behavior depends on the error type, scenario settings and handler configuration. A repeated downstream write can still create a second CRM record, task or message.
Keep the source event identity separate from the Make execution ID. For an inbound event, a proposed row grain is one source event, identified by source_system + source_event_id. For an AI execution, use a separate illustrative grain such as workflow_id + run_id. Do not use a startup name, process name or date as a universal deduplication key. Citations, daily summaries and CRM contacts are different row types and require different identifiers and aggregation scopes.
Use destination-enforced uniqueness, a transactional upsert or another verified idempotency mechanism. Test concurrent duplicate delivery, not only a sequential replay. The destination operation, rather than the retry setting alone, must decide whether the event has already been applied.
Before launch, test repeated delivery, missing fields, rate limits, uncertain downstream responses and failed writes. Require human review for low-confidence AI suggestions, sensitive data, external messages, destructive changes and consequential CRM updates. Name the person who resolves exceptions before enabling the scenario.
A practical first-automation decision
Start with a frequent, bounded, low-consequence process that has a known owner and an observable completion condition. A first pilot might validate inbound requests into an approved CRM or turn workshop notes into a reviewed process brief, but neither pattern should write to production until the startup confirms its own systems, permissions, data-processing requirements and destination behavior.
Confirm Make-STATION F office access and any program eligibility directly. Separately verify every connector, data permission and desired data source. The partnership announcement does not establish access to campus data or an integration with STATION F systems.
- A named process owner approves the scope and exception route.
- The source, destination and permitted data path are verified.
- Connections use only the access needed for the workflow.
- Duplicate writes are prevented by a tested destination mechanism.
- Failed writes and unresolved cases reach a human owner.
- A baseline and measurable completion condition are recorded.
If any item is unresolved, keep the process manual or run a non-writing pilot until it is settled. That is a useful result of process discovery: a clear, testable scope before automation begins.
