Live data from Hacker News

Launch HN: Human Layer (YC F24) – Human-in-the-Loop API for AI Systems

news.ycombinator.com

191–200 of 206 posts

Re: Launch HN: Human Layer (YC F24) – Human-in-the-Loop API for AI Systems

#191
post #25

Startup owner using AI with this need - needless to say, a real problem. I've considered DIYing an internal service for this - even if we went with you we'd probably have an intern do a quick and dirty copy, which I rarely advocate for if I can offload to SAAS. I'm sure you've put a fair bit of work into this that goes well beyond the human interaction loop, but that's really all we need. Your entry price is steep (I…

thanks for the validation of the problem! totally open to feedback about the solution, and totally get that you only need something simple for now. I want to point out that we do have a pay-as-you-go tier which is $20 for 200 operations, and have a handful of indie devs finding this useful for back-office style automations. ALSO - something I think about a lot - if a all/most of the HumanLayer SaaS backend was open s…

Honestly: don't spend your time on HN comments like this. Focus on customers who want to pay you for it.

Re: Launch HN: Human Layer (YC F24) – Human-in-the-Loop API for AI Systems

#192
post #2

P.S. nobody asked but since you made it this far - the next big problem in this space is fast becoming, what else do we need to be able to build these "headless" or "outer loop" AI agents? Most frameworks do a bad job of handling any tool call that would be asynchronous or long running (imagine an agent calling a tool and having to hang for hours or days while waiting for a response from a human). Rewiring existing f…

I've been using the DBOS (dbos.dev) framework to do this in a non-AI app that sends out render jobs, but imagine the process is no different for any other long-running request/response scenario:

1. Run the whole process in a workflow function. Give the run a unique ID, which can be used to automatically deduplicate runs, and will be used to look up the workflow later. This fires off the request in a "step" function, and calls `recv` to wait for a response. The request should include a key that can be used to calculate the workflow ID. 2. DBOS automatically "stores the context somewhere" because of the `recv` 3. A separate HTTP handler in DBOS catches the webhook, and uses the key in the response to calculate the ID of the workflow from #1. 4. The HTTP handler calls `send` with that ID, so that the workflow can pick up whatever response is sent 5. The original workflow resumes with the response from `send` 6. The original workflow can do whatever it wants with the response

DBOS provides reliability around the whole thing (restarts any workflows in the case of any server restarts), and provides some tracing for the process out of the box, so it was quite simple to get started, and have it hosted in DBOS cloud , which also provides a public IP so that the external service can send a webhook response.

Re: Launch HN: Human Layer (YC F24) – Human-in-the-Loop API for AI Systems

#193

Earlier quoted context omitted.

Essentially, you don't need to think about time and space. You just write more or less normal looking code, using the Temporal SDK. Except it actually can resume from arbitrarily long pauses, waiting as long as it needs to for some signal, without any special effort beyond using the SDK. You also automatically get great observability into all running workflows, seeing inputs and outputs at each step, etc. The cost of…

helpful - thanks! I have played with temporal a bit but have this thought that since most AI tools represent state as just a rolling context window, maybe you don't have to serialize and entire call stack and you can cut a bunch of corners. but we're all probably better off not investing that wheel

IMO just a rolling message history works for only the simplest of AI tools. Useful agents will tend towards much more complex state that extends into specific verticals/domains.

Re: Launch HN: Human Layer (YC F24) – Human-in-the-Loop API for AI Systems

#195
Congrats on the launch. Seems quite interesting!

My only queation/feedback is: What policies do you have in place to prevent bad outsourcing or exploitative behavior like what has been done by big-tech companies that turn a blind eye to what happens in, for example, Kenya [0] for the training of AI models?

[0]: https://youtu.be/qZS50KXjAX0

Re: Launch HN: Human Layer (YC F24) – Human-in-the-Loop API for AI Systems

#196
post #64
post #35

Interesting tool, congrats on the launch! I was wondering: have you thought about automation bias or automation complacency [0]? Sticking with the drop-tables example: if you have an agent that works quite well, the human in the loop will nearly always approve the task. The human will then learn over time that the agent "can be trusted", and will stop reviewing the pings carefully. Hitting the "approve" button will b…

this is fascinating and resonates with me on a deep level. I'm surprised I haven't stumbled across this yet. I think we have this problem with all AI systems, e.g. I have let cursor write wrong code from time to time and don't review it at the level I should...we need to solve that for every area of AI. Not a new problem but definitely about to get way more serious

You could continually learn a distribution over AI responses and search for outliers to surface with urgency for approval.

Re: Launch HN: Human Layer (YC F24) – Human-in-the-Loop API for AI Systems

#198

Earlier quoted context omitted.

>DNS+SES+SNS+Lambda+Webhooks+API+Datastore+Async Workers so that everything would "just work" with a few lines of humanlayer sdk. What are you smoking my man? Write a python script that begins with the 2 following lines "import openai import email " Simple is better than complex

hmm, like, i love simplicity, and I'm open to other approaches, but I specifically wanted to solve the "send an email to an AI Agent" sort of concept, and give that agent rails to talk back the the human. Doesn't `import email` require SMTP, DNS, signing infra, etc? can it set up MX infra and receive payloads from a mail exchange?

Import email IS smtp.

MX and SPF is as trivial as with providers. Dkim might be harder. But emails will still go through.

You can also rent an smtp server and have a similarly simple infra where you log in to the server to read and send emails.

If this is too complex, I'd recommend starting with a private protocol like discord, which is designed for kids, or telegram as an intermediate step.

Re: Launch HN: Human Layer (YC F24) – Human-in-the-Loop API for AI Systems

#199
post #64

Earlier quoted context omitted.

this is fascinating and resonates with me on a deep level. I'm surprised I haven't stumbled across this yet. I think we have this problem with all AI systems, e.g. I have let cursor write wrong code from time to time and don't review it at the level I should...we need to solve that for every area of AI. Not a new problem but definitely about to get way more serious

You could continually learn a distribution over AI responses and search for outliers to surface with urgency for approval.

i like this idea - runtime inference based on past responses that gets smarter dynamically is a really interesting space

Re: Launch HN: Human Layer (YC F24) – Human-in-the-Loop API for AI Systems

#200

Startup owner using AI with this need - needless to say, a real problem. I've considered DIYing an internal service for this - even if we went with you we'd probably have an intern do a quick and dirty copy, which I rarely advocate for if I can offload to SAAS. I'm sure you've put a fair bit of work into this that goes well beyond the human interaction loop, but that's really all we need. Your entry price is steep (I…

Hey, would you be open to checking out something I hacked together on GitHub? https://github.com/adrian-kong/hitl-middleware

I wasn’t sure if this would be relevant to you or useful at all, but it’s a quick solution I built for HITL workflows. Happy to hear your thoughts or if you think it’s applicable!

Post reply on HN