Zyk's First Chapter — and Why We Changed Direction

When I started building Zyk, the goal was a workflow definition you could actually read. YAML, stored in git, no proprietary tooling. But still backed by a proper workflow engine with all the reliability, retries, and scheduling that serious automation requires.

I got far enough into it to see the problem. A YAML DSL is still a DSL. It still has limits. And the moment your workflow needs something the DSL does not support, you are back to fighting the tool. The format changed but the constraint did not.

The real problem with visual workflow development

Connecting a few services in a visual workflow tool takes two weeks. Not because the APIs do not exist. Not because connectors are missing. But because wiring services together visually is slow by nature. You map fields by hand. You debug expression languages. You trace why a value from step two is not arriving correctly in step four. You fight the tool when you should be solving the business problem.

The friction is not a missing feature. It is structural to how visual development works. And it compounds as workflows grow.

What the next generation looks like

Large language models have read the documentation for most APIs in the world. They understand authentication patterns, request shapes, error handling, and pagination. They can reason about how services connect to each other. And they can write the integration code in seconds, not days.

The missing piece was always reliability. Writing code is one thing. Making it retry on failure, resume after a crash, run on a schedule, and stay observable over time is another. That is now solved by modern durable execution engines that handle all of it without you building any of it.

Put these two things together and something shifts. You describe your workflow in plain language. The code gets written for you, real code you can read and version. It runs reliably underneath. And you never spend two weeks mapping fields in a visual editor again.

We believe the future of automation is conversational. And we believe current LLMs are already capable of writing workflows that are consistent, predictable, and production-ready. Not because they are magic, but because workflows are a narrow, well-defined problem. Give an LLM clear instructions, define the boundaries, and it produces reliable code. The scope is contained enough that this works today, not in some future version of the technology.

Where Zyk is going

The new version of Zyk is built on this idea. You describe your workflow to Claude in plain conversation. Claude writes it as real code, not a DSL, not a JSON config, actual TypeScript that you can read, version, and modify. A visual diagram updates live as the workflow takes shape so you always see what you are building. The workflow gets registered with a durable execution engine and runs reliably, with retries, scheduling, and monitoring built in.

No connector library to maintain. No drag-and-drop boxes. No vendor lock-in to a proprietary workflow language. Just a conversation, some generated code, and a reliable runtime underneath.

See it in action: Workflow automation without the drag-and-drop

An incident response workflow, described in plain conversation, deployed live, resolved with a single Slack button click.

This is a meaningful shift from what Zyk was. But it is not a retreat from the original goal. The goal was always to make serious workflow automation accessible to teams that should not need a dedicated workflow engineer to get things done. The first version took one step toward that. This version takes a bigger one.

Every workflow is automatically versioned in git in the background. You never touch a repository or write a commit message. But you get the full history of every change, the ability to roll back to any previous version just by asking, and a human-readable audit trail of everything that has ever run. The conversation is your interface. Git is your safety net. You never have to think about either.

This makes Claude your workflow designer and task manager in one. Not a visual editor with boxes and arrows. Not a terminal. Just a conversation where you describe what you need, watch it get built, and know it is running reliably underneath.

We are building it now. If you want to follow along or get early access, you know where to find us.