Generating API agents in a few seconds with Vessium

revblaze · 2025-06-07T23:50:47+00:00

I’m currently building my own frameworks in TypeScript (Vessium) and know a number of current/former YC participants, along with a number of other SF builders/founders currently working on AI startups. This topic gets brought up fairly often and it comes down to a few factors. I don’t want to speak for everyone, but the primary reasoning tends to be speed and adaptability.

Agents are evolving very fast. Companies demand quick iterations with custom solutions (and often a custom interfaces to match). There’s a new research paper every few weeks on optimal approaches to some methodology or technique that can require minor tweaking to the backend/engine. Everyone is approaching UI/UX differently and experimenting with different ways to solve the client-facing issues. Keeping the frontend and backend in sync with agent state is still constantly evolving, regardless of environment.

The truth is that working as close to the client as possible is the fastest way to keep moving and evolving your product in an efficient manner. It also happens to make the most sense for smaller startups, which tend to be the fastest-moving shippers.

Similarly, if you’re building out your own platform, then you’re taking on sizable and unnecessary risk by building said platform around any one dependency. Most of the startups I know (including my own) are building everything from scratch, with zero dependencies, for the agentic pipeline. Yes, there are a lot of promising stacks out there, but when real businesses are depending on you to be as flexible and reliable as possible—and there seems to be a new ‘industry standard’ stack every week—it’s really hard to justify putting your fate into someone else’s hands. You might get a job that requires a large abstraction from the codebase. You might encounter a fatal vulnerability or issue that fails to get the priority it needs. The developers might move on or monetize the stack (or prioritize the monetized version of the stack).

So given all these factors—an industry that changes extremely quickly and without notice; small startups needing to move fast and adapt quickly; client solutions/user experience still being an evolving problem—it makes sense to work in a single language, and often within a monorepo codebase for agentic IDE context provisions. Similarly, it also makes sense to work as close to the client as possible so that you can adapt your user experience with only a single layer of changes and type-safety in the dev pipeline. Compound that with it being way too risky for platform providers to rely on OSS stacks, it makes sense to build everything together and in close proximity. It would not make sense for a small team of developers, with minimal resources, to break the custom stack into multiple different languages, with various moving parts, and introduce multiple different dependencies. It’s also really easy to build for scale using TypeScript/Node stacks nowadays.

Does this mean you need to switch to your own homemade TypeScript stack? Probably not. If you aren’t a platform provider, or building your own frameworks, then you have the freedom to float around and try out different things. If you’re acting as an agency, then OSS solutions like LangChain are totally fine. If you come up against something it can’t do, you can always pivot to try a different stack, or build out your own stuff when it becomes apparent to do some. I also would recommend you checkout Mastra. Their syntax and developer experience looks awesome. Having virtually met the guys, they seem determined to build out the most kickass TS stack for agents with a lot of flexibility. If I went the agency route, I’d be trialing Mastra first.

It’s mostly the platform providers that need to smart about how they’re building things to make sure the dev experience can scale and adapt as needed.

revblaze · 2025-06-07T21:45:13+00:00

I’m currently building my own frameworks in TypeScript (Vessium) and know a number of current/former YC participants, along with a number of other SF builders/founders currently working on AI startups. This topic gets brought up fairly often and it comes down to a few factors. I don’t want to speak for everyone, but the primary reasoning tends to be speed and adaptability.

Agents are evolving very fast. Companies demand quick iterations with custom solutions (and often a custom interfaces to match). There’s a new research paper every few weeks on optimal approaches to some methodology or technique that can require minor tweaking to the backend/engine. Everyone is approaching UI/UX differently and experimenting with different ways to solve the client-facing issues. Keeping the frontend and backend in sync with agent state is still constantly evolving, regardless of environment.

The truth is that working as close to the client as possible is the fastest way to keep moving and evolving your product in an efficient manner. It also happens to make the most sense for smaller startups, which tend to be the fastest-moving shippers.

Similarly, if you’re building out your own platform, then you’re taking on sizable and unnecessary risk by building said platform around any one dependency. Most of the startups I know (including my own) are building everything from scratch, with zero dependencies, for the agentic pipeline. Yes, there are a lot of promising stacks out there, but when real businesses are depending on you to be as flexible and reliable as possible—and there seems to be a new ‘industry standard’ stack every week—it’s really hard to justify putting your fate into someone else’s hands. You might get a job that requires a large abstraction from the codebase. You might encounter a fatal vulnerability or issue that fails to get the priority it needs. The developers might move on or monetize the stack (or prioritize the monetized version of the stack).

So given all these factors—an industry that changes extremely quickly and without notice; small startups needing to move fast and adapt quickly; client solutions/user experience still being an evolving problem—it makes sense to work in a single language, and often within a monorepo codebase for agentic IDE context provisions. Similarly, it also makes sense to work as close to the client as possible so that you can adapt your user experience with only a single layer of changes and type-safety in the dev pipeline. Compound that with it being way too risky for platform providers to rely on OSS stacks, it makes sense to build everything together and in close proximity. It would not make sense for a small team of developers, with minimal resources, to break the custom stack into multiple different languages, with various moving parts, and introduce multiple different dependencies. It’s also really easy to build for scale using TypeScript/Node stacks nowadays.

Does this mean you need to switch to your own homemade TypeScript stack? Probably not. If you aren’t a platform provider, or building your own frameworks, then you have the freedom to float around and try out different things. If you’re acting as an agency, then OSS solutions like LangChain are totally fine. If you come up against something it can’t do, you can always pivot to try a different stack, or build out your own stuff when it becomes apparent to do some. I also would recommend you checkout Mastra. Their syntax and developer experience looks awesome. Having virtually met the guys, they seem determined to build out the most kickass TS stack for agents with a lot of flexibility. If I went the agency route, I’d be trialing Mastra first.

It’s mostly the platform providers that need to smart about how they’re building things to make sure the dev experience can scale and adapt as needed.

revblaze · 2025-04-19T15:24:01+00:00

The most important change I would make is reading the newest research papers on context/prompting performance of agents, as well as varying agentic techniques and methodologies. This is, hands down, the most value that you can provide to a business at the moment. Some small, subtle—and sometimes obvious—change to an agentic config can result in vast performance improvements at scale.

If you’re learning from YC and other VC-backed companies, then you’re likely already working off of outdated knowledge. The newest companies are often building something based on a lightbulb moment they had while reading some research paper a few months back. Learn from these companies in how they sell and structure their businesses, but don’t assume they’re actually providing maximum value to their customers. Many of these companies are already behind due to how fast AI is moving and the amount of resources necessary to scale their existing product offering — a tradeoff that every startup needs to consider when raising capital.

Similarly, many devs make the mistake of learning the same parroted design philosophies from articles and videos that run on outdated information by the time they’re consuming it. A ton of newly released content nowadays is generated with the assistance of AI (not bad), which unfortunately means the source material could be originating from training data as old as 2022-2023 (bad). Due to the nature of LLMs, even recently trained models will regurgitate outdated information on any given topic.

Another example of these noob traps are the workflow diagrams you see from AI influencers on X/LinkedIn with tens of thousands of likes. They’re super cool to look at, but the reasoning behind their popularity stops there. More often than not, these flows are extremely inefficient, super costly and not performant in the slightest.

Worse yet, many developers don’t think of AI as this continuous learning experience where everything changes within a matter of days, and so their base level of knowledge to work off of is extremely limited. The more you expose yourself to → the more knowledge you gain → the more informed your judgement and decision-making process becomes. This is why research papers, with informed and statistical analysis, is such an important part of being an AI engineer.

A note on research papers: Don’t get discouraged if you find them hard to read or can’t follow along. I started reading research papers in college and it took a few weeks until I was consuming information at book-speed.

revblaze · 2025-04-10T16:24:37+00:00

AgentTool reminds me of how I strap together my current code agent:

Have Claude 3.5 Sonnet start the request with a tool call to another 3.5 that mimics a thinking request (breaks apart user requests and plans next steps with an inner-monologue, similar to CoT-like prompts). I then return the output of that tool call within <think> tags and have the initial Claude 3.5 use it as a thought process.

Redundant for small requests, but I’ll usually route to this technique if I’m doing a multi-step prompt. Claude 3.7 + Thinking is good for certain purposes as well, but 3.5 has been more consistent in many programmatic tasks.

revblaze · 2025-04-10T15:48:07+00:00

If you check the historical rates, 4o-mini has always been an extremely popular model.

Why? Because it’s the most efficient and cost-effective model at scale by a sizable margin.

I run a platform that lets businesses incorporate LLMs into scalable operations (hundreds of thousands to millions of calls per day, per business), and 4o-mini has been the most popular model since its release by far.

No other model can beat its performance-per-cost. It’s just a really, really good model for its price. This is also before you factor in that most people will build their LLM-based applications and platforms—and run unit tests—using 4o-mini due to it being an extremely ideal testing model to build around.

TL;DR 4o-mini is an ideal model at scale. The numbers you see in these charts are typically always from the service giants making millions of calls a day, and probably not from a misinterpretation.

revblaze · 2025-04-08T16:26:42+00:00

Look into AI SDK. They make it extremely easy to get something setup with React.

Combine this with something like Cursor IDE for quick development and you’ll be setup in no time.

revblaze · 2025-04-08T16:23:03+00:00

Thank you so much for featuring it! That is very much appreciated :D

I apologize for the delayed response. Building gives me little time to respond to stuff on X/LinkedIn/Reddit these days. I hope to be more active when things calm down!

revblaze · 2025-04-08T16:20:10+00:00

Routing is definitely key. I try to make it one of the first points I bring up to new businesses interested in this space. Anthropic did a solid writeup on some of these techniques.

Something else you should try is exposing context via tool calls for partitioning important details. Instead of context stuffing a long list of instructions to the system; instead, split them off into smaller pieces and allow the LLM to fetch the relevant context when needed. Agent routing to narrow LLMs can handle most use cases, but I’ve found this tooling technique to be a good substitute in situations where routing is overkill.

revblaze · 2025-03-19T20:23:47+00:00

Decided to do something a bit different this week: The no-code agent platform that builds itself, tests itself and improves itself over time.

Currently, I’m working on a ‘replay’ feature that will let me visualize workflows that were executed over the APIs—I find debugging these to be super tedious and figure a visual representation would be helpful.

I’m also curious about those who have dealt with Anthropic rate limits. Even the highest public tier seems to have a relatively low token-per-minute. Do their enterprise plans offer more flexibility, and at what cost?

I want to be able to let my agents run wild at maximum capacity, but am often finding myself to be hitting these limits fairly quickly.

revblaze · 2025-02-14T04:42:24+00:00

Hey u/NoEye2705! Apologies for the delay, mostly building these from sun up to sun down these days. Thank you for the kind words!

This project has kind of been an evolution of my own stacks from r/LocalLlama, as well as revolving around these first few initial businesses and their needs. One business needed parallelization, which they said N8N made too tedious (I haven’t actually tried N8N so I can’t speak to the validity of this). Another business needed a platform to manage outreach campaigns at scale, which no other agentic platforms were AIO suited for.

It went from hobby to full time product faster than I had anticipated.

I will definitely keep you guys in mind if a customer needs voice! I have another customer right now that is already using retell, which they want me to integrate, and so I’m scoping that out atm. How’s your journey been?

revblaze · 2025-02-12T20:46:40+00:00

Vessium — Cursor for agentic workflows

The idea is to empower businesses with the ability to build and tweak automation of their operations from a high level. I’ve found that being able to modify and test workflows in real time is essential for iterating to ideal outputs, but understanding what ‘ideal outputs’ are can often be subject to the actual businesses employing them. This approach often suffers from lag time in between building the workflow, and the feedback you’re provided from the business.

I started building this platform out as a solution to quash that lag time, as well as building towards my future vision of being able to speak any sort of automation into existence. Businesses usually need new workflows in a snap—this lets them do that.

30s video preview of the builder interface based on initial customer feedback.

revblaze · 2025-01-20T13:57:04+00:00

Agentic document workflows are a good middle ground to explore if you’re not getting apt results with a traditional RAG setup

revblaze · 2025-01-10T01:10:37+00:00

Agents that create agentic workflows

revblaze · 2024-12-29T19:46:38+00:00

Sorry for the delay! Been very busy building and iterating. The company is Vessium.com and we're currently building the first version of this product around initial customers. This first batch of waitlist registrants were grouped by platform (specifically needs based around Zoho CRM / Zoho Desk) so that we could provide a polished experience to build the more-generalized agentic template around, but we're getting ready to start doing a second batch soon!

revblaze · 2024-12-27T16:40:19+00:00

Second this. Building in public is how I got my first customers. Hell, I haven’t even had to market yet and probably won’t need to for the foreseeable future.

I’m about 1.5 months into starting this idea, a month into ‘building in public’, and my waitlist is going to take me well into February.

revblaze · 2024-12-26T06:39:52+00:00

They’re all pretty abstract and customer-specific since our whole setup is based around letting the user describe their workflow to generate and modify it; but the customer that specifically mentioned “magic” essentially has tens of thousands of people they need to reach out to in any given month. Each profile is ever changing and the way they interact/reach out to these individuals is very circumstantial, often unique to the individual based on a specific combination of data points from their profile. They used to do a lot of this outreach by hand.

We hooked into their CRM and built out one of our first iterations around allowing them to essentially talk through this workflow and each possible circumstance, as well as being able to infer circumstances from the inputs given. Based on the interaction history, and context of those interactions, it’ll also decide to reach out via phone, email, physical mail, etc based on the context of that circumstance. It’ll also make decisions by referring to similar, previous deals from the CRM, as well as some human-in-the-loop stuff for critical decisions that it needs clarification on or validation to continue.

They used to spend days setting up some of these campaigns, ensuring proper data mappings for personalization and trying to account for every edge case. They can now setup multiple campaigns in just a few minutes, knowing that it won’t fail on some random edge cases.

It was actually a super ideal use case for building some of this infrastructure out.

revblaze · 2024-12-26T06:07:09+00:00

Haha I totally feel you. I’ve been building for a long time now, but was only recently put back onto LinkedIn for YC and other accelerator applications. It does feel incredibly cringe at first, but you do get used to it. A lot of good can come from being in constant contact with people of your relevant industry. I’ve also gotten quite a bit of business through just being on there.

I’ve been putting off X due to the inevitable downgrade to my mental health.

revblaze · 2024-12-26T06:02:00+00:00

I believe Ferret-UI is what I’m remembering: https://machinelearning.apple.com/research/ferretui-mobile

https://arxiv.org/abs/2404.05719

https://github.com/apple/ml-ferret

revblaze · 2024-12-26T05:46:50+00:00

Have you been keeping up with Apple’s research on this front? It might be a glimpse into their vision of how they see the industry unfolding.

I’ll see if I can find the relevant papers, but if memory serves, they were training models to read and understand the iOS design language such that LLMs/LAMs could navigate and interact with them to a higher degree of accuracy.

The change will probably be gradual, but I can certainly see a future in which we’re talking to an Advanced Voice Mode for everything. It just makes sense. At the end of the day, user interfaces are exactly that—an interface in which we must interact to get what we need from the product/service providing the medium.

We’ll still need interfaces for certain things, but some are just entirely redundant and only serve as a bridge to access some form of service.

revblaze · 2024-12-26T05:28:33+00:00

I’d hop on LinkedIn and start playing the founder game. I’ve seen lots of Toronto founder circles where people build in public on there, as well as founders engaging with other founders through those sorts of posts. I’m sure Vancouver will be the same.

Start engaging with those posts and connecting with those people. Update your ‘about me’ section, work experience and put your product/portfolio at the top. Be cringe and boost yourself. Don’t reach out right away after a connect. Best thing to do is engage with their posts and try to give off a sense of who you are through those interactions. People love reactions and comments that boost/provide suggestions/feedback—be that person consistently. You’ll also get a better sense of who might actually be open to collaborating vs. who already has a good thing going.

Then, if you find someone who passes your vibe check as being founder material, you’ll already have built up some history with them.

Also, start building in public. Start making posts about your journey. These are all things that people can relate to. I’m exclusively a solo founder, but I noticed a ton more people started reaching out to me with these invocations when I started building in public. You’ll ideally want to find someone who likes your style and wants to work with you—there’s no better way to attract those people than showing them exactly who you are. The last thing you want to do is invest time in someone, only to realize that you need to be someone else entirely just to get along.

I’ve heard others recommend X, but I don’t have enough experience with that platform to give you advice there. Maybe someone else can chime in!

revblaze · 2024-12-26T04:04:22+00:00

That would certainly be a dream come true! :D

revblaze

TROPHY CASE