yohamta

MCP is a gateway protocol, not tool use.

Yes, as long as a senior SWE guides AI agents properly.

In Japan still many system integrator company that large corporation relies on continue using waterfall approach. They keep to out source a lot of engineering work for making design documents, manual testing, etc. They would keep to hire many middle class engineers.

As a Japanese in Tokyo, I didn't know that Ramens in other countries look so good.

Multiplayer agent harness is useful only when the context and AI output does not overwhelm the team space and works asynchronously and background. If you think about it, that could be just boring job scheduler, isn't it?

Anthropic SOTA model is a gift to human. Open AI model is so annoying. I alway feel like talking to intelligent insects,

I built Dagu, a simple workflow engine and lightweight alternative to Airflow.

Lately, I’ve been using it to automate my daily workflows with an AI agent harness like opencode. Dagu helps you manage local, private workflows. It gives you a flexible Kanban-style view, a declarative workflow language with validation, and the basics you expect from production workflow infrastructure: logs, retries, status tracking, and more.

The best part of having a workflow language is maintainability. Any AI agent can help create or debug your workflows. You can do something similar with plain Bash scripts, but Bash quickly becomes hard to debug and maintain.

Because Dagu is DAG-based, it automatically runs independent steps in parallel. Each step is validated and logged separately, which makes it much easier for an AI agent to understand what failed and fix it.

Give it a try!

This is a very interesting project, especially since I've been building a similar declarative workflow engine for over 5 years. With a well-designed YAML schema, it's now possible to build workflows with AI agents. I call this "Vibe workflows."

There's no need for humans to write DAGs anymore, yet they remain human-readable. I truly believe this is the future of workflow orchestration.

https://github.com/dagucloud/dagu

exe.dev は大好きなプロジェクトです。単一の仮想マシン/ローカルマシンに全てを詰め込むアイデアが好きです。私は単一マシン上でのワークフローオーケストレーションの複雑性に関わる問題を解決するため Dagu.sh を開発しています。

Claude and Open AI seems to be trying not to be 'Just a model', but this is intrinsically problematic because model can be degraded and prices only goes up once they lock-in customers. It is increasingly important for anyone who are responsible of managing 'AI workflows' to keep the sovereignty about how you use AI models. This is why I'm super excited in building the local-first workflow orchestration software called "Dagu", that allows us to own your harness on your own. It's not only more cost-effective, but outcome is better as well because you have 100% full control. I think it's only matter of time that people notice they need to own their workflow orchestration on their own not relying on Anthropic, OpenAI, or Google.

AI agent orchestration is future. That's where workflow engine shines. I'm doing the same thing using Dagu.sh and I don't use terminal so much anymore.

Hey HN! I'm excited to share Dagu v1.18, a major release of our lightweight workflow orchestration engine that works on shared filesystem.

Dagu is designed for teams that find Airflow overkill but need more than cron. It's a single binary with zero dependencies that runs anywhere - from Raspberry Pi to cloud clusters.

What's new in v1.18:

- Distributed execution - Run workflow steps across multiple machines - OIDC authentication - Enterprise-ready auth for the Web UI - High availability - Redundant schedulers with automatic failover

Example workflow: ``` steps: - name: fetch data command: curl https://api.example.com/data output: DATA

      - name: process
        command: python process.py
        env:
          - INPUT: ${DATA}
        retryPolicy:
          limit: 3
          intervalSec: 30
          backoff: 2.0

```

No need for a database or complex setup. Just write your YAML workflow and run it with `dagu start my_workflow.yaml`.

Would love to hear your feedback!

I'm wondering if it is possible to find out the exact system instruction for these GPTs

It seems the correct command is "cargo build --target wasm32-unknown-unknown --release".

Thanks for the article. I tried it but somehow the compilation command doesn't work on my local: "$ cargo run --target=wasm32-unknown-unknown --release" error: a bin target must be available for `cargo run`

Thanks for the comment :) That's a good point. We considered using Airflow in the first place, but we decided not to. Because we had only a few number of developers and felt those tools were overkill for our use case. Also, we couldn't afford those tools' additional overheads such as operational costs or learning curves. We just wanted a better Cron that can be easily installed and operated and is capable of visualizing and running DAGs.

I work as a software developer for a Japanese company, developing and maintaining large ETL(Extract, Transform, Load) pipelines that have been maintained for many years.

I am developing jobctl with Go. https://github.com/yohamta/jobctl/

Why?? What is the motivation?

Currently, my environment has many problems. Hundreds of complex cron jobs are registered on huge servers and it is impossible to keep track of the dependencies between them. If one job fails, I don't know which job to re-run. I also have to SSH into the server to see the logs and manually run the shell scripts one by one.

So I needed a tool that can explicitly visualize and manage the dependencies of the pipeline.

How nice it would be to be able to visually see the job dependencies, execution status, and logs of each job in a web browser, and to be able to rerun or stop a series of jobs with just a mouse click!

Why not alternatives?

Well, I considered many potential tools such as Airflow, Rundeck, Luigi, DigDag, JobScheduler, etc.

But unfortunately, they were not suitable for my existing environment. Because they required a DBMS(Database Management System) installation, relatively high learning curves, and more operational overheads. We only have a small group of engineers in our office and use a less common DBMS.

Finally, I decided to build my own tool that would not require any DBMS server, any daemon process, or any additional operational burden and is easy to use.