DEV Community: Archit Singhal

SponsorProof — A Campaign Checker for Content Creators

Archit Singhal — Sun, 18 Oct 2026 17:37:26 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Creators can spend hours preparing sponsored videos, only to discover that their script contains the wrong discount code, a missing hashtag, or a claim the sponsor prohibited. These mistakes cause unnecessary revisions and delay approvals.

SponsorProof compares a brand's campaign brief with a creator's script or caption to identify potential issues before submission.

It is designed for:

-Independent content creators managing sponsorships.

-Freelance video editors reviewing sponsored content.

-Small marketing agencies handling creator campaigns.

The project checks campaign requirements such as promotional codes, hashtags, sponsorship disclosures, sponsor links, prohibited claims, competitor mentions, and required talking points.

A potential business model would be a free version for individual creators and a paid team version for agencies that need shared briefs, reports, and collaboration features.

Demo

Live website: https://sponsorproof.onrender.com

The website includes an example NordShield VPN campaign. Its brief requires the promo code CREATOR70, while the example script contains CREATOR20. The audit workflow is designed to identify this mismatch and other campaign requirements that need attention.

The hosted website currently supports deterministic audit mode. Gemma-powered analysis runs through my local Ollama setup; the hosted Ollama model connection is not yet configured. I am sharing this limitation rather than claiming that hosted AI analysis works.

Code

GitHub repository: https://github.com/architsinghal0005/sponsorproof

The repository contains the application source code and project documentation.

How I Built It

I built SponsorProof using:

-Next.js for the web application.

-TypeScript for application logic and type safety.

-Tailwind CSS for the user interface.

-Gemma 3 1B through Ollama for local AI inference.

-Rule-based validation for exact campaign requirements.

-Render to deploy the public web application.

One key design decision was to combine deterministic checks with AI. Exact requirements, such as promotional codes and hashtags, are better handled with predictable rules. A language model can help interpret more nuanced instructions, but its findings still need verification.

Running Gemma locally also gave me a way to experiment with open-weight AI without depending entirely on a paid hosted model API. Local processing can keep campaign material on the user's machine when the application is configured not to send that material elsewhere.

The hosted deployment and local AI setup are separate at this stage, and connecting the hosted application to a reliable model endpoint remains future work.

Why Does Open Innovation Matter?

Open innovation makes it possible for individual developers to experiment with AI and build useful tools without depending entirely on closed, proprietary services.

Using an open-weight model such as Gemma gives developers more flexibility over where inference runs, how prompts are designed, and how a model is adapted to a specific workflow.

For SponsorProof, this matters because campaign briefs and unreleased scripts can contain sensitive business information. Local inference offers an opportunity to process that material locally, provided the application does not transmit it elsewhere.

Open models also make experimentation more accessible: developers can test different approaches, inspect failure cases, and combine AI with conventional software engineering techniques.

There are trade-offs. Local inference requires suitable hardware, smaller models can miss context, and AI-generated findings should not be treated as legal or advertising-compliance certification.

SponsorProof is a prototype exploring how open-weight AI and deterministic software checks can work together to reduce repetitive review work.

Prize Categories

-Best Use of Gemma

-Best Use of Render

Beyond Chatbots: How Fetch.ai Is Helping AI Agents Work Together

Archit Singhal — Sun, 18 Oct 2026 16:43:42 +0000

I use AI for a lot of things, from debugging code to getting my head around a new concept. But I've noticed that getting an answer and getting something done are not the same thing.
Say you ask an AI to plan a weekend trip. It'll happily list places to visit. Then you're the one checking the weather, comparing buses and trains, hunting for hotels, and trying to keep it all under budget. The AI gave you ideas, and you still did the work.
It would be nice if different AI systems could split that work between them. That's what people mean by agentic AI.
**

So what is agentic AI, really?

**
A regular chatbot mostly reacts. You ask, it answers. An agent is built to work toward a goal over several steps. It might pull data from an API, use a tool, message another agent, and change what it does next based on what came back.
It doesn't have to run on a large language model, either. Some agents just follow predefined rules and call APIs. Others use an LLM to understand a request and make decisions.
What I find interesting is that agents don't have to work alone. A few specialised ones can team up on something that would otherwise take several separate apps.
That doesn't mean handing AI the keys to everything. Permissions, error handling, and a human sign-off still matter, especially when money or personal data is involved.
**

Why a platform like Fetch.ai?

**
Building one agent is the easy part. Getting different agents to find each other and talk is harder.
Picture one developer building a weather agent and another building a transport agent. Both are useful. But how would an app discover them? How do they share information? How does a regular user get to use them?
Fetch.ai tries to cover that gap with tools for building agents, making them discoverable, and connecting them to users. Three pieces matter most.

uAgents: build your own agents The uAgents Framework is an open-source Python framework for building autonomous agents. You decide how an agent behaves, how it handles incoming messages, and how it talks to other agents. You could write a weather agent that fetches forecasts and a transport agent that returns route info, then have a third agent combine the two to plan a journey. Instead of one giant app that does everything, you get small, focused pieces. The framework gives you the building blocks. The actual functionality and integrations are still up to you. Want to try it? Create your first uAgents agent.

2.Agentverse: make agents findable
Once you've built something useful, how does anyone else find it?
Agentverse is where agents get registered, discovered, hosted, and managed. The point is that developers don't have to build everything from scratch. An app can look for existing agents that already do what it needs.
One caveat: being listed doesn't make an agent reliable or trustworthy. You still need to validate what comes back and plan for things going wrong.

3.ASI:One: connect users to agents
ASI:One is an AI interface meant to link users with specialised agents. You say what you need, and compatible agents can step in through supported integrations.
If you want to see how that works in practice, Fetch.ai has an ASI:One agent integration example.
Put together, the three cover different parts of the problem: building agents, helping people find them, and letting users reach them.
**

A simple example

**
Say you're planning a two-day trip to Jaipur on a tight budget. A multi-agent app could handle it like this:

A planning agent takes in your destination, dates, and budget.
A weather agent pulls the forecast from an outside source.
A transport agent compares routes and prices.
An accommodation agent collects hotel options that fit.
The planning agent pulls it all into one itinerary. Instead of juggling a handful of websites, you get a single plan. To be clear, this is an illustration of what could be built, not a feature Fetch.ai gives you out of the box. Someone still has to build the agents, hook up the APIs, and write the coordination logic. And if booking or payment ever enters the picture, it needs proper permissions and safeguards. **

How to get started

**
You don't need to train your own language model to play with this. Start with Python and some basic API work. Then follow the uAgents documentation and build one small agent that does one useful thing.
Once that works, build a second agent and get the two exchanging messages. After that, poke around Agentverse and the ASI:One integration example.
Even a tiny working setup will teach you a lot about communication, coordination, and what happens when things break.
**

Final thoughts

**
What draws me to agentic AI is the idea of connecting specialised systems rather than expecting one model to do everything. Fetch.ai offers a way to explore that through uAgents, Agentverse, and ASI:One. Reliability, security, and coordination are still open problems, but there's a lot of room to experiment.
For me, the question isn't just how smart a model can get. It's how well we can connect that intelligence to the tools and services that solve real problems.
Maybe the next step in AI isn't one assistant that knows everything, but a network of specialised agents that work well together.