Skip to content

Agentic SaaS Authoring

M15 focuses OpenUdon on AI-assisted authoring for common SaaS workflows. The authoring assistant may help clarify goals, choose operations, draft request mappings, and explain unresolved assumptions. Once project.md and workflows/intent.hcl are ready, the rest of the path is deterministic: validate, build, review, package, approve, and hand off to a trusted executor.

n8n and ../try-n8n are service-priority evidence for this track. They help identify useful services, common operations, and provider vocabulary. OpenUdon does not run n8n workflows, import n8n internals, or add n8n-specific UWS semantics for this milestone. The n8n Pattern Bridge formalizes that evidence as a small advisory summary format; it is not an executable importer.

Authoring Contract

The supported authoring flow is:

  1. Start from a natural-language goal or guided cmd/icot session.
  2. Select local or catalog-migrated API artifacts only after OpenUdon validates provider and artifact keys against the deterministic shortlist.
  3. Select listed operation IDs only; concrete operations are not accepted from early catalog planning.
  4. Draft project.md with inputs, outputs, data flow, runtime policy, credential binding names, safety, and fallback behavior.
  5. Draft workflows/intent.hcl with auditable with and bind mappings.
  6. Run deterministic build and assessment commands.
  7. Review generated evidence before any trusted-runner handoff.

AI output is a draft, not an execution permission. Side-effectful calls such as send, create, update, delete, upload, or post remain review-required until a human approves the package and the trusted runner receives a valid approval artifact.

Service Priority Corpus

The first SaaS corpus is selected from existing OpenUdon evals plus ../try-n8n reducibility evidence. These services are common enough to teach the authoring path without making n8n import the product interface. See SaaS Authoring Corpus for the M16 fixture policy, readiness matrix, and graduation criteria.

Service Starter Operation Operation ID Binding Name Readiness Notes
Slack Post a message postMessage slack_bot_token Existing native and n8n-derived fixtures cover side-effect review.
Gmail Send a message sendMessage gmail_oauth_token Existing fixture covers generated send response and audit evidence.
Jira Create or fetch an issue createIssue, getIssue jira_api_token Existing IT Ops fixtures cover Slack-to-Jira handoff.
HubSpot List CRM records listDeals, listTickets hubspot_private_app_token n8n-derived fixtures supply provider vocabulary and OpenAPI slices.
Google Drive Upload a file uploadFile google_drive_oauth_token Existing IT Ops archive fixture covers document handoff; Drive-specific graduation is deferred.
Airtable Get a record getAirtableRecord airtable_api_key Existing native and n8n-derived fixtures cover record lookup.
PagerDuty Fetch a user getUser pagerduty_api_token Existing fixture covers nested response extraction.
Trello List board lists listTrelloBoardLists trello_api_token Native fixture covers list summarization; n8n evidence owns the provider operation ID.
OpenWeatherMap Fetch current weather getOpenWeatherMapCurrentWeather openweathermap_appid n8n evidence covers provider-specific weather; generic native fixture covers the read-only pattern.

OpenAPI Readiness

Each service slice should be authoring-ready before it graduates from advisory evidence to a strict golden fixture:

  • local OpenAPI file is present under openapi/;
  • selected operations have stable operationId values;
  • required path, query, header, and body fields are visible to the prompt;
  • request and response schemas expose the fields used in with, bind, and outputs;
  • security schemes can be mapped to symbolic binding names;
  • server URLs, examples, and enums are present when they affect request shape;
  • no credential values or production tenant IDs are stored in examples.

When any of those inputs are missing, the authoring assistant should leave the field unresolved or explain the assumption instead of inventing unavailable provider behavior.

iCoT may use a compact catalog plan immediately after the first workflow goal to pick relevant cached artifacts and provider-level steps. That plan is advisory: OpenUdon validates every selected artifact locally and rejects unknown paths. Operation IDs, schemas, request fields, response paths, and credentials still come later from reviewed local API source metadata.

Before final confirmation, LLM-assisted iCoT may run one advisory flow review over the complete draft. That review is limited to cross-step data-flow mistakes that deterministic schema checks may miss; it reports warnings but does not rewrite the draft by default. Each warning is locally normalized into a flow-gap kind plus remediation action, and unresolved warnings are written back as non-executable intent.hcl comments. Experimental --review-repair may make up to two bounded repairs to request mappings, output sources, or depends_on; it may also add a local fnct transform/report/render step when the goal clearly asks for produced content and exactly one existing producer step can feed it. It rejects source, operation, credential, side-effect-scope, and ambiguous structural mutations. When the remaining issue is true user-intent ambiguity, iCoT asks one forced question even in fast mode.

Mapping Rules

For each SaaS API step, make review evidence easy to audit:

  • name the API source file and operation ID;
  • map every required request field to an input, safe literal, prior-step output, or credential binding name;
  • let the LLM draft obvious mappings from selected operation metadata, but keep unresolved or low-confidence mappings visible for operator review;
  • use bind for prior-step data flow and keep depends_on on the consumer step;
  • record response paths used by later steps or final outputs;
  • identify side-effect scope for send/create/update/delete/upload/post actions;
  • keep provider-specific secrets out of prompts, examples, and artifacts.

Golden Fixtures

OpenUdon-native golden fixtures remain the regression target. n8n-derived fixtures are advisory evidence until the OpenAPI slices and credential policy are complete enough for strict comparison.

  • examples/eval/slack-message-audit-log is the initial native SaaS authoring fixture. It documents an AI-authoring contract in reference/authoring.json.
  • examples/eval/gmail-send-audit-receipt and examples/eval/itops-slack-jira-issue-intake join Slack as the M16 initial strict SaaS golden set.
  • examples/eval/itops-incident-response-archive and related fixtures cover follow-on service patterns before they graduate into strict provider-specific coverage.
  • examples/eval/n8n-* fixtures preserve n8n provenance in reference/n8n.json. Selected M22 fixtures also include reference/n8n-bridge.json summaries for service, operation, credential, and unsupported-semantics evidence. They stay diagnostic unless their policy graduates them to strict mode.