GenAIAPIGen

Inspiration

Agents are the next wave of GenAI. I was curious what would happen if we tried to represent an API endpoint, service or path with an Agent. In a way this would mimic the way a company would work where a person is a contact for a department, you would have an agent responsible for portion of the API.

What it does

We show an evolution from a single request endpoint, to 2 x agent endpoints, and then to N-agents for a given API specification, with each agent representing a particular path.

How we built it

We used a combination of Gemini and CrewAI (and langchain indirectly) to build it.

Challenges we ran into

The cherry on top didn't quite get working. We were hoping to show not only agents responding to requests but also to have them create the code for the endpoints they're responsible for. This was close but we couldn't reliably accomplish the goal. I feel Gemini-1.5-pro may have been able to do so but would have required higher rate limits.

Accomplishments that we're proud of

It works. It's fun. It's not practical today for so many reasons. BUT it's interesting to represent an API this way. It can respond to humans wanting to "chat with it about it's capabilities" and for other agents to request actual data, all within the same code. It's also significantly less code than alternatives.

What we learned

This works but it's slow, expensive, and not really a replacement for current Service Registry + API Gateway solutions. That said, it's likely to need less code to implement and has hardware gets faster, it may become more viable.

What's next for GenAIAPIGen

We'll continue to investigate the viably of dynamic code generation in this solution. If we achieve it, it would make the solution much more valuable because, in theory, I can write an API spec, have some database classes, and then let the LLMs do the rest of the work creating the functions to respond to requests.

Built With

• crewai
• gemini
• langchain
• vertexai