FIELD

OPS / AUTOMATION / TOOLS

STATUS

AVAILABLE · REMOTE

CSEXECUTION TRACE

Ascend Flow

A reusable platform for running, monitoring, and inspecting Python automations — designed to be installed into any project by an AI agent with a single prompt.

CONTEXT

Internal platform · public template

ROLE

Solo build

STACK

Python, Docker, Railway

YEAR

2026

01 — The problem

Automations accumulate. A Make.com scenario here, a cron script there — each one works, none of them are visible. When something fails silently, you find out from the downstream mess, not from the system. And every new project reinvents the same plumbing: how to run flows, where the logs go, how a non-developer checks whether last night's run succeeded.

Ascend Flow is the answer built once: a platform template that gives any project the same runway — scheduled Python flows, structured runs, and a UI where anyone can inspect what happened.

FIG · FROM SCRIPT OR BLUEPRINT TO AN INSPECTABLE, DEPLOYED FLOW · CLICK TO ENLARGE

02 — Constraints

  • Each project needs its own isolated instance — one shared automation server becomes a shared point of failure and a permissions nightmare.
  • Non-developers have to be able to answer "did it run, did it work?" in a browser, without reading logs.
  • Flows are increasingly written by AI agents, so the SDK has to make the right pattern the only easy pattern — flat steps, compact structured output, searchable metadata, and hard rules against logging secrets or raw customer data.
  • Existing automations live in Make.com; there had to be a migration path that doesn't mean rebuilding from scratch by hand.

03 — The approach

The template ships as a repo any project copies in: an API, a web UI with a flows list and a run inspector, an ascend_sdk for authoring (step(), log_output(), set_metadata()), and deploy config for an isolated instance per project.

The unusual part is the installer: it's a prompt, not a script. The README is written to be pasted into a coding agent, which inspects the target repo, installs the platform, and converts the first automation from whichever source exists — a Python script or an exported Make.com blueprint JSON. The agent reads the blueprint and rewrites it as a proper Python flow; Make scenarios become inspectable, versioned code.

The SDK's constraints are the quality system: flat steps only, output that stays compact and JSON-serializable, metadata that makes runs searchable by source system, batch, model, or cost. An agent that follows the rules produces a flow that looks like every other flow — which is exactly the point.

The code is public: github.com/Luis-GHP/ascend-flow.

04 — The outcome

Ascend Flow is the foundation other systems in this portfolio run on — the signal-triggered outreach system is an Ascend Flow instance. New projects get monitored, inspectable automation infrastructure in one agent session instead of an afternoon of plumbing, and "is it working?" is a browser tab, not a log dive.

05 — What I'd do differently

Settle the logging and metadata conventions before writing the first real flow — the earliest flows predate the rules and needed retrofitting to match them. And the prompt-based installer, while it proves the AI-first idea, wants a thin CLI wrapper for the parts that never vary.

← BACK TO HOME