Comment by Palmik

Comment by Palmik 2 days ago

13 replies

View on Hacker News

The example from the landing page does not exactly spark joy:

    testWorkflow
     .step(llm)
       .then(decider)
       .then(agentOne)
       .then(workflow)
     .after(decider)
       .then(agentTwo)
       .then(workflow)
      .commit();
On a first glance, this looks like a very awkward way to represent the graph from the picture. And this is just a simple "workflow" (the structure of the graph does not depend on the results of the execution), not an agent.
campers 2 days ago

I get the same feeing when I first looked at the LangChain documentation when I wanted to first start tinkering with LLM apps.

I built my own TypeScript AI platform https://typedai.dev with an extensive feature list where I've kept iterating on what I find the most ergonomic way to develop, using standard constructs as much as possible. I've coded enough Java streams, RxJS chains, and JavaScript callbacks and Promise chains to know what kind of code I like to read and debug.

I was having a peek at xstate but after I came across https://docs.dbos.dev/ here recently I'm pretty sure that's that path I'll go down for durable execution to keep building everything with a simple programming model.

Reply View 3 replies
  • nwienert 2 days ago

    Kind of similar camp, I checked LangChain and others and ultimately I was like, well, it's not really doing much is it, just adding abstraction on top of what is essentially basic loops and conditional statements, and tbh it feels like in nearly every case I'll never be using them the same way such that some abstraction will help over just making some function helpers myself.

    I don't think from first principles there's any broad framework that makes sense to be honest. I'll reach for a specific vector DB, or logging library, but beyond that you'll never convince me your "query-builder" API is going to make me build a better thing when I have the full power of TypeScript already.

    Especially when these products start throwing in proprietary features and add-ons with fancy names on top.

    Reply View 0 replies
  • jumski 2 days ago

    TypedAI looks solid, was not aware of it! Bookmarked for further research.

    Personally I am not fond of the decorator approach and decided to not use it in pgflow (my soon-to-be-released workflow orchestration engine on top of Postgres).

    1. I wanted it to be simple to reason about and explicit (being more verbose as a trade-off)

    2. There are some issues with supporting decorators (Svelte https://github.com/sveltejs/svelte/issues/11502, and a lot of others).

    3. I decided to only support directed acyclic graphs (no loops!) in order to promote simplicity. Will be supporting conditional recursive sub-workflows to provide a way to repeat some steps and be able to branch.

    Cheers!

    Reply View 0 replies
calcsam 2 days ago

Thanks! The conditional `when` clauses live on the steps, rather than being represented in the workflow, and in fact when we built this for an example, the last step being called depended on the results of the previous two steps.

How would you simplify this?

Reply View 5 replies
  • anentropic 2 days ago

    I think the problem is that a 'fluent' chain of calls already expresses a sequence, so the way that 'after' resets the context to start a new branch feels very awkward ... like a GOTO or something

    It's telling that the example relies on arbitrary indentation (which a linter will get rid of) to have some hope of comprehending it

    Possibly this was all motivated by a desire to avoid nested structures above all?

    But for a branching graph a nested structure is more natural. It'd also probably be nicer if the methods were on the task nodes instead of on the workflow, then you could avoid the 'step'/'then' distinction and have something like:

    e.g.

        testWorkflow(
        llm
        .then(decider)
        .then(
            agentOne.then(workflow),
            agentTwo.then(workflow),
        )
    )
    Reply View 2 replies
    • calcsam 2 days ago

      You’re right that the syntax was inspired by the desire to avoid nested structures. But the syntax here is interesting as well and fairly readable. Worth thinking about!

      Reply View 1 reply
      • anentropic 21 hours ago

        that example syntax is loosely based on CDK code for AWS Step Functions, since I had to write some recently

        essentially you're building a DAG so it could be worth checking some other APIs which do a similar thing for inspiration

        e.g. it looks like in Airflow you could write it as:

            chain(llm, decider, [agentOne, agentTwo], workflow)
        https://airflow.apache.org/docs/apache-airflow/stable/core-c...
        Reply View 0 replies
  • jumski 2 days ago

    I think it is just easier to comprehend if the edges/dependencies are explicit (as an array for example).

    Reply View 1 reply
    • calcsam 2 days ago

      We have a ticket to allow this actually!

      Reply View 0 replies
jumski 2 days ago

Yeah, I also found this a bit unintuitive at first. I’m building a workflow engine myself (https://pgflow.dev/pgflow, not released yet), and I’ve been thinking a lot about how to model the DSL for the graph and decided to make dependencies explicit and use method chaining for expansion with other step types.

Here’s how it would look like in my system:

  new Flow<string>()  
    .step("llm", llmStepHandler)  
    .step("decider", ["llm"], deciderStepHandler)  
    .step("agentOne", ["decider"], agentOneStepHandler)  
    .step("agentTwo", ["decider"], agentTwoStepHandler)  
    .step("workflow", ["agentOne", "agentTwo"], workflowStepHandler);
Mine is a DAG, so more constrained than the cyclic graph Mastra supports (if I understand correctly).
Reply View 0 replies
[removed] 2 days ago
[deleted]
Reply View 0 replies
zeroq 2 days ago

I knew it will be bad when I seen "by the developers of Gatsby", but this is pure comedy.

JQuery plugin for LLM.

Reply View 0 replies