A sovereign [REDACTED] Rfp agent

• 

Inspiration

Every two weeks, the DevHub team and I prepare a proposal and invoice summarizing our contributions to DevHub. I keep a log of my work, which I manually transfer to DevHub biweekly. After approval, I submit an invoice to the NEAR Foundation with the title, hours worked, hourly rate, and a link to the approved proposal. To streamline this, I’d like to develop an agent to interact with the DevHub contract and automate these steps on the fly. Another agent could also interact with the Request Finance API to further simplify invoicing.

Additionally, before creating any proposals, there’s the RFP (Request for Proposal) process.

These pain points exist across various committees (like the Infrastructure Committee and AI-PGF) and could benefit from similar automation.

Platform owners, such as DevHub admins, members of the Infrastructure and Events Committee, and the AI-PGF team from Potlock, should have an easy way to deploy these RFPs as well.

What it does

My agent helps the user to interact with the DevHub's smart contract to add proposals and RFP's.

RFP

The user can use prompts like;

Create an RFP with the labels ["Bridges", ] the title "Hello AI", summary "I'm creating this RFP with an AI Agent", description "# RFP AI AGENT building the future of smart contract interaction" the submission deadline is 27-10-2024 on the infrastructure-committee.near contract

or

Create a RFP on infrastructure-committee.near

And the the agent will ask for the details it needs to create the transaction.

Proposal

Create a proposal on devhub.near with the category "DevDAO Platform", the title "DevHub Developer Contributor report by THOMAS", summary "I contributed to NEAR DevHub", description "## Summary of Activities", I agree with the terms and conditions, amount 100, currency "NEAR", my account id is thomasguntenaar.near

or

Create a proposal on devhub.near

And the the agent will ask for the details it needs to create the transaction.

How I built it

To streamline RFP and proposal workflows, I built the agent using a mix of back-end and smart contract technologies, leveraging the existing infrastructure and AI tools.

The DevHub smart contract was already deployed and in active use across multiple platforms. To start, I forked Bitte's Ref Finance agent template as a foundation, using it as the basis for my interactions with the DevHub contract.

To enable contract interactions, I used Bitte’s smart actions to structure communication between the agent and the DevHub contract. By defining each interaction in an OpenAPI specification, I ensured that Bitte’s Engine had clear instructions for API communication. This setup allows the agent to create transactions based on user prompts, ensuring each proposal and RFP adheres to the necessary data requirements.

With the structured OpenAPI spec, the LLM can parse API responses and automatically generate the transaction HTML component, providing users with a final review step. This human-in-the-loop approach remains essential as a last guardrail, allowing users to confirm or decline each transaction before submission.

Challenges we ran into

It's a long list so I split them up in two categories, but here are just a few:

AI challenges

• The biggest challenge with these agents is their limited contextual understanding. As a developer working with this contract, I have insight into the purpose and business use cases behind each function. The agent lacks this depth of experience, and simply adding more context doesn't necessarily improve its performance.

• Context can also differ depending on the user interacting with the agent. For instance, admins create RFPs, while developers respond to them and draft proposals. The agent needs to recognize and adjust to these role-based differences.

• While the agent performs well on narrow tasks, it struggles with consistency when handling more complex workflows.

Programming challenges

• devhub.near is a big contract, I first started building out endpoints for the majority of contract methods. It turns out that the big API spec results in a big context which confuses Bitte's engine and makes it work sometimes. To resolve this issue I started creating multiple agents with small API spec's. Every method would have their own dedicated agent and dedicated spec. This was to make them as small as possible. I later discovered that we were only allowed 1 project submission for this hackathon so I had to ditch the multi agent again for a single agent with just a smaller set of features.
• Another mistake I made was to use the make-agent contract devhub.near command and trust its output too much. It generated an API spec that was not made for Bitte's agent. It put me on the wrong path for quite a while until I figured out that the spec structure was just nonsense.
• The add_rfp and add_proposal functions both have very complicated parameter structures for smart contracts. They are by no means easy for a LLM to interpret correctly. I started out by building a huge api spec full of parameter specification.. My best guess; the big context again made it hard for the LLM to know what to do. So I tried to make an endpoint with more guard rails against hallucinations.
• The agent example project updated to support testnet in a later stage of the hackathon. I noticed that something had changed in the API. The json response of the OpenAPI spec wasn't automatically formatted again and it seemed like the the LLM became more inconsistent.
• The ai-pgf interface has an additional requirement to create a project under Potlock first and then ai-pgf. I haven't found a solution let the AI agent check this requirement before interacting with their contract yet.

What we learned

• Bitte's agent is a very promising technology. Any tasks that is repeated over an over again could be done by software and these agents make it easier to build workflows than ever before.

• Forking and deploying these agents is very beginner friendly and a great way to get more developers into AI.

What's next for the sovereign [REDACTED] RFP agent

What is next is adding functionality to add more text to the body without updating the whole proposal body. For this some contract changes are needed or a lot more guard rails need to be build for the agent to hallucinate less. This could be accomplished by an endpoint that directly accepts a single body and parsing that body with an LLM in the API myself. Allowing more control over I/O.

After that would have been accomplished we can create an agent that interacts Request Finance's API. This would take prompts like; "Send near foundation an invoice for my last approved proposal!".

It would also be cool to add the possibility for custom HTML elements to Bitte. Allowing the user to look over the invoice's fields before sending anything. If proposals have been approved I want the agent to be able to call https://api.request.finance/invoices and basically copy the fields to the off chain invoice. The end user checks if all fields are correct and sends it with a single click.

Accomplishments that we're proud of

I'm proud because

• This is my first hackathon submission.
• This is my first experience working with AI agents.
• Successfully integrated Bitte’s agent framework with complex DevHub contract structures
• And finally I'm proud on NEAR for reclaiming our sovereignty!

Built With

• bitte
• nextjs
• vercel