emil14

Short guide explains `-p, -parallel, and t.Parallel()` in Go programming language for parallel testing

1) You said about process but pointed to operation

2) What wrapping would you add out there? (Wrapping must be added in provider's implementations though)

3) No, user shouldn't and can't handle errors by implementing operation handler. To handle error it simply uses go's native mechanism "v, err := ... ; if err != nil", it just needs to be done once instead of doing so for every operation in the process

> you add additional non-openai providers.

100% will do, just not for the initial release

> fwiw I really like agency's interceptor funcs, good place to add tracing, metrics, logging, etc.

thank u much, glad to hear it :)

Think of ORM for LLMs. That's not the whole purpose of "langchain-like" frameworks but on that is easy to grasp

> Using someone else's abstractions for your entire workflow is a nice way of making a hackathon project

We use someone else's abstractions all the time, when they are good :) Think of reactjs, expressjs, django, etc.

> Abstracting away the flows (agency/langchain) is the wrong layer of abstraction

But you do abstract away SQL when you write business logic isn't it? Many people uses ORMs for that, which gives ability to easily switch databases and write tests. Why do you think this isn't the same?

> langchain had hardcoded prompts, which make it difficult to experiment and iterate

Agency does not and won't have anything like that except it's going to make a LOT of sense. Even then there 100% will be to control that stuff.

> Where is the complexity hidden?

The biggest complexity was to design the library to be small, simple and extensible. It's not a lot of abstractions out there.

But the better answer to your question is probably something like - "complexity is hidden behind how providers implement core interfaces"

UPD: bug with temperature fixed in master

We think that too! Agency won't have implicit prompts. Or at least without explicit and easy way to override them

I think the intention behind langchain is good, but the implementation suffers from bad design. We tried to fix that by having small core with as less abstractions as possible.

1) your 30 lines could become 10 lines or something

2) you can write abstract code without explicit dependency on openai and easely switch to e.g. anthropic in future without rewriting the whole thing (think of ORM for LLMs)

3) ready to use abstraction like Process that allows to chain operations (more complex stuff is much easier than writing by hand)

yeah but it's not go (and go-centric)

1) Thank you for pointing the moment with 0 temp, I think we can make `agency.TextToTextParams{Temperature *int}` where nil gonna be passed down like `0` and 0 gonna be mapped to `math.SmallestNonzeroFloat32`. We also will add the ability to use seeds though

2) "I was hoping this would be a drop in replacement for langchain" - why don't use use langchaingo then? The thing is - we don't like langchain much. To is it looks too complex, we thing we can do better, simpler. The final goal is to make a library that can replace langchain and/or autogen but it's definitely not gonna be "drop-in" replacement

Correct me if I'm wrong but looks like this is a helper-utility to work with openai API. Agency on the other hand gives you tools to abstract away such things and write high level code

Actually error handling is much easier with agency's Processes (pipelines)

Instead of writing:

result, err := operationFoo(userInput) if err != nil { panic(err }

result, err = operationBar(result) if err != nil { panic(err }

You can create a Process and handle errors only once:

result, err := agency.NewProcess(operationFoo, operationBar).Execute(userInput) // ...

Imagine having 3+ operations, like 5 or 10. That's gonna be some real difference.

All the chained methods like `SetPrompt(...)` returns `agency.Operation` and no error needs to be handled there

Thank you for your comment :)

Why do you think that "method chaining is not really idiomatic" or how this should be implemented?

Thank you, fixed, MIT license added

Small core, simple api, openai bindings

Service and a library written in Go that allows you to synchronize transaction history of specified accounts.