EmberGround AI Hackathon 2026
Finding Problems Agents Can't Solve Overnight
AI can already write the code.
The interesting question is: what should we build that code alone cannot solve?
AI coding agents such as Claude Code and Codex have dramatically changed what a small team can build in a day.
A developer can now describe a feature, inspect a codebase, connect tools, manipulate files and data, build interfaces, run tests, and iterate much faster than before. Claude Code supports MCP servers and tool permissions, while Codex is explicitly being used for tasks such as cleaning tabular data, querying spreadsheets, synthesizing information from multiple sources, and automating workflows.
That changes the question for a hackathon.
A few years ago, the challenge was:
"Can you build it?"
Increasingly, the answer is:
"Probably."
So the interesting challenge becomes:
"Is this worth building?"
And more importantly:
"Does this problem contain something that a general-purpose AI coding agent cannot simply reproduce in a weekend?"
This guide is here to help you find that problem.
1. The Commodity Layer Is Moving Very Fast
A useful way to think about today's AI stack is:
AI MODEL │ ▼ CODING / AGENT │ ┌────────┴────────┐ │ │ MCP APIs │ │ ┌──────┼──────┐ ┌─────┼─────┐ ▼ ▼ ▼ ▼ ▼ ▼ Gmail GitHub DB Slack CRM Payments
The agent can increasingly reach the tools.
Then platforms such as n8n add another layer:
Trigger ↓ AI Agent ↓ Tool ↓ API ↓ Action ↓ Another system
So building:
"An AI assistant that connects Gmail + Slack + Notion"
is unlikely to be a defensible hackathon idea.
It may still be useful.
But it is not where the most interesting product opportunities are.
The same applies to:
- another generic RAG chatbot
- another PDF chat application
- another AI CRM assistant
- another AI email writer
- another meeting summarizer
- another "ask your database" interface
- another generic multi-agent system
- another AI dashboard
- another CRUD application with an LLM on top
These can often be recreated extremely quickly once the underlying integrations and models already exist.
2. The Real Opportunity Is Above the Tools
Imagine that your AI agent has access to:
- your database
- CRM
- calendar
- payment system
- documents
- analytics
- internal APIs
You might think:
"The agent can now run the business."
Not quite.
It has access.
Access is not the same as understanding.
And understanding is not the same as safely completing work.
The missing layers look more like this:
BUSINESS │ ▼ ┌─────────────────┐ │ Messy reality │ └────────┬────────┘ │ fragmented information │ ▼ ┌─────────────────┐ │ Business model │ │ + context │ └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Agent reasoning │ └────────┬────────┘ │ ┌─────────┼─────────┐ ▼ ▼ ▼ Insight Decision Action │ │ │ └─────────┼─────────┘ ▼ Human control │ ▼ Real world
This is where we want you to explore.
3. What Makes a Problem Interesting?
A good hackathon problem has at least one property that makes it hard to replace with a generic AI agent.
Look for problems involving:
1. Persistent context
The system needs to remember what happened weeks or months ago.
2. Messy real-world data
The information doesn't arrive as a clean JSON schema.
It arrives as:
- spreadsheets
- photographs
- PDFs
- voice messages
- WhatsApp conversations
- invoices
- handwritten records
- inconsistent names
- incomplete information
3. Long-running execution
The job doesn't finish after one response.
It may take:
- hours
- days
- multiple interactions
- external events
- retries
- human intervention
4. Human judgment
The agent cannot simply "do everything."
Someone needs to approve:
- money
- sensitive decisions
- exceptions
- legal commitments
- customer-impacting actions
5. Physical-world consequences
Something eventually happens outside the computer.
A technician travels.
A package moves.
A patient visits a facility.
A payment is made.
A machine is repaired.
A crop is harvested.
A document is submitted.
6. Local context
The problem depends on:
- Indian languages
- local business practices
- local regulations
- local infrastructure
- fragmented markets
- local trust networks
- informal processes
7. A workflow rather than a task
A task:
"Summarize this invoice."
A workflow:
"Make sure this supplier actually gets paid correctly."
The second is much more interesting.
4. Don't Ask "What Can AI Do?"
Ask:
"Where are humans currently acting as the glue?"
This is one of the best ways to discover a hackathon problem.
Consider a small business.
The owner may have:
Excel + WhatsApp + Phone calls + Bank account + Email + Accounting software + Human memory
None of these systems necessarily understands the complete situation.
The owner becomes the integration layer.
They remember:
"This customer normally pays late."
They know:
"Don't send this supplier a reminder yet."
They remember:
"We promised this customer delivery before Friday."
They understand:
"That spreadsheet entry is wrong."
They decide:
"This payment is safe."
That human context is often the actual product opportunity.
5. India Is Full of These Problems
India is particularly interesting because enormous parts of the economy are simultaneously:
- digitally connected
- operationally fragmented
- multilingual
- highly distributed
- dependent on small businesses
- dependent on human coordination
This creates a very different opportunity from simply building another SaaS dashboard.
For example, ONDC itself describes barriers faced by smaller businesses including limited online visibility, fragmented fulfilment, high customer-acquisition costs, and limited interoperable technology infrastructure. Its materials also note that many sellers need substantial hand-holding because they have limited prior e-commerce experience.
That doesn't mean:
"Build an ONDC assistant."
It means:
Look for the human coordination hidden inside these systems.
6. Problem Area: Small Business Operations
A typical small business may not have a dedicated:
- operations manager
- data analyst
- collections team
- procurement team
- customer-success team
- compliance team
One person may perform all of these roles.
That creates opportunities around:
Receivables
A business knows customers owe money, but someone still has to:
- identify overdue accounts
- understand the history
- decide whom to contact
- communicate
- negotiate
- track promises
- verify payment
- escalate exceptions
Delayed payment is a documented issue for Indian micro and small enterprises. The Ministry of MSME operates the Samadhaan system for delayed-payment complaints, and government materials describe the cash-flow consequences of delayed payments and gaps involving manual case management, documentation, communication and legal processes.
The opportunity isn't:
"Build an invoice chatbot."
Ask instead:
Where does the business lose time between "money is owed" and "money is actually resolved"?
7. Problem Area: The Spreadsheet Is Often the Last Mile
There is a misconception that spreadsheets are primitive.
They aren't.
For many businesses, spreadsheets are powerful because they are flexible.
The problem is that they contain business state without business intelligence.
Someone may maintain:
Customers.xlsx Orders.xlsx Inventory.xlsx Payments.xlsx Employees.xlsx
But the spreadsheet doesn't necessarily know:
"These three things require attention today."
And it doesn't necessarily know:
"If this supplier is delayed, these seven customer orders will be affected."
This is where the next generation of business software could become interesting.
Don't simply build:
Excel + ChatGPT
Instead explore:
What would a business workspace look like if the interface were generated around the decision the user is trying to make?
The interface might become:
"Why are orders late?" ↓ Investigation ↓ 12 delayed orders ↓ Root causes Supplier A Transport B Inventory C ↓ Actions [Contact supplier] [Reassign shipment] [Notify customers]
The interface changes according to the problem.
That is much more interesting than adding a chat box to Excel.
8. Problem Area: Long-Running Work
Many AI demos assume:
User ↓ Agent ↓ Answer
Real businesses often look like:
Request ↓ Investigate ↓ Contact someone ↓ Wait ↓ Receive response ↓ Interpret response ↓ Make decision ↓ Ask human ↓ Execute ↓ Wait ↓ Verify ↓ Close
This is a fundamentally different problem.
Render Workflows is designed specifically for this class of system: it provides managed task queuing, chaining, retries, state and observability, with individual task runs configurable up to 24 hours.
So don't build:
"An agent that runs for a long time."
Instead ask:
What real-world process actually needs to remain alive?
Potential areas include:
- procurement
- claims
- collections
- service requests
- maintenance
- onboarding
- compliance
- logistics exceptions
- dispute resolution
- document processing
- scheduled follow-ups
The interesting part is not the timer.
The interesting part is:
What happens while the agent is waiting?
9. Problem Area: Human-in-the-Loop
There is another important distinction.
A bad autonomous agent says:
"I'll handle everything."
A useful agent knows:
"This part is safe to automate."
and:
"This part needs you."
Consider a payment.
The agent may be able to:
- identify the invoice
- verify the customer
- calculate the amount
- check payment history
- prepare the transaction
But before the money moves:
AGENT │ ▼ ┌──────────────┐ │ Risk / Policy│ └───────┬──────┘ │ ┌─────────┴─────────┐ ▼ ▼ SAFE RISKY │ │ ▼ ▼ Auto-execute Human approval │ ▼ Execute
This creates a much more interesting design space:
How should an agent decide when it is allowed to act?
The challenge is no longer just AI.
It becomes:
- authorization
- policy
- auditability
- explainability
- identity
- reversibility
- escalation
These are much harder to "vibe code" away.
10. Problem Area: Money
Payments are especially interesting because an agent can move from:
information
to:
consequence
A generic coding agent can easily create:
[Pay ₹500]
The difficult problem is:
Should the agent be allowed to pay ₹500?
And:
Who authorized it?
And:
What if the amount changed?
And:
What if the recipient changed?
And:
What if the payment happens twice?
And:
What if the agent misunderstood the invoice?
This is where payment becomes an agent-control problem, rather than a payment-integration problem.
A strong project should make the authorization model visible.
For example:
Low-risk action ↓ Automatic Medium-risk action ↓ User confirmation High-risk action ↓ Human approval Unknown / anomalous ↓ Stop
The exact policy is up to the builder.
The important thing is that the policy exists.
11. Problem Area: Voice Is Not Just Text-to-Speech
Voice is another area where it is easy to build the wrong thing.
Today, ElevenLabs Agents can already support conversational agents, external tools, knowledge, workflows and multilingual interactions; ElevenLabs documents support for 31+ languages in its agent platform and much broader language support in newer conversational models.
So:
"I made ChatGPT speak Hindi"
isn't enough.
The interesting question is:
What interaction becomes possible because the user can speak naturally instead of using a screen?
For example, consider someone who is:
- driving
- working in a field
- repairing equipment
- running a shop
- caring for someone
- uncomfortable with complex software
- communicating primarily in a regional language
The opportunity is not the voice itself.
The opportunity is the workflow unlocked by voice.
12. India's Multilingual Reality
India isn't simply:
English → Hindi.
People routinely communicate using combinations of:
- English
- Hindi
- regional languages
- transliterated text
- local terminology
- abbreviations
- names
- product codes
- pronunciation variants
Modern voice systems can already support many Indian languages. ElevenLabs, for example, lists Hindi, Bengali, Gujarati, Kannada, Malayalam, Marathi, Nepali, Punjabi, Tamil, Telugu and Urdu among its supported languages.
Therefore don't make the hackathon challenge:
"Build a multilingual chatbot."
Instead:
Find a workflow where language is currently preventing a person from accessing or completing something.
That is a much better problem.
13. Problem Area: Memory
Agents can have context during a conversation.
But businesses often need something different:
Institutional memory.
Imagine a customer who spoke with a business three months ago.
The important information isn't just:
"What did they say?"
It's:
"What have we learned about this person?"
Maybe:
- what they previously rejected
- what they prefer
- what they promised
- what the company promised
- what was already tried
- what failed
- who is responsible
- what should never happen again
That becomes valuable when the agent is operating over weeks or months.
The opportunity is therefore not:
"Add a vector database."
Ask:
What decisions become better when an agent remembers the history of the relationship?
14. Problem Area: The Physical World
This is one of the strongest areas for hackathon ideas that cannot be trivially replaced by Claude Code or Codex.
Software agents live in computers.
India exists in the physical world.
Consider:
- construction
- agriculture
- logistics
- repair
- healthcare
- manufacturing
- retail
- waste management
- field inspections
- infrastructure maintenance
A coding agent can generate the software.
It cannot magically:
- visit the site
- inspect the machine
- speak to the technician
- move the inventory
- repair the equipment
- verify the delivery
- negotiate with the person standing there
This creates a valuable boundary.
The AI system becomes the coordination layer between digital intelligence and physical work.
15. A Very Useful Question: "Where Does the Agent's World End?"
For every idea, draw this line:
COMPUTER ──────────────────────────── Agent Database API MCP n8n LLM UI ──────────────────────────── REAL WORLD Customer Employee Technician Supplier Vehicle Machine Money Government office Patient Physical location
The closer your problem gets to crossing that boundary, the more interesting the system can become.
Not automatically.
But it forces you to deal with reality.
16. Problem Area: Logistics and Distributed Operations
India's logistics ecosystem is highly distributed.
ONDC describes the last-mile ecosystem as fragmented, with fleet ownership spread across many operators and supply disconnected from demand in different regions.
This creates problems that aren't simply:
"Find the shortest route."
The real problem may involve:
- availability
- reliability
- timing
- human communication
- exceptions
- changing conditions
- multiple operators
- customer expectations
- failed deliveries
- returns
- payment
A route optimizer can be built quickly.
A system that manages the exception lifecycle is more interesting.
Ask:
What happens when reality doesn't follow the plan?
17. Problem Area: Small Producers Entering Digital Commerce
ONDC's own material highlights barriers for grassroots producers and small sellers including:
- market access
- digital visibility
- logistics
- packaging
- cataloguing
- onboarding
It also notes that many small sellers require handholding rather than simply being given a login and an API.
This is exactly the kind of problem that can generate interesting agentic systems.
Not:
"Build an AI e-commerce website."
Instead:
What parts of becoming digitally operational still require a human to guide the seller?
That might involve:
physical product ↓ photos ↓ catalogue ↓ pricing ↓ inventory ↓ listing ↓ order ↓ packaging ↓ delivery ↓ return ↓ payment
The interesting product might sit across that entire journey.
18. Problem Area: Healthcare Administration
Healthcare is another domain where the temptation is to build:
"AI doctor."
Don't.
The more interesting opportunity is often around the clinical interaction rather than replacing the clinician.
India's ABDM initiative is explicitly working toward interoperable health infrastructure; the Ministry of Health reported more than 72 crore ABHA numbers and more than 47 crore linked health records as of December 31, 2024.
That creates an interesting design space around:
- coordination
- records
- follow-ups
- referrals
- appointment logistics
- patient communication
- document collection
- multilingual interaction
- operational workflows
The question becomes:
Where does information get lost between one healthcare interaction and the next?
That is a very different problem from:
"Can an LLM diagnose a patient?"
19. Problem Area: Government and Compliance Workflows
Government processes are another area where a chatbot is rarely the core problem.
The actual difficulty can be:
Understand requirement ↓ Collect documents ↓ Check eligibility ↓ Resolve missing information ↓ Submit ↓ Wait ↓ Receive response ↓ Interpret response ↓ Fix problem ↓ Resubmit ↓ Track
An agent that answers:
"What documents do I need?"
is useful.
But an agent that can manage the entire case lifecycle is a much deeper product problem.
The key challenge is trust:
Can the system show exactly why it believes something is required and what evidence supports the next action?
20. Problem Area: Exceptions
This might be the single most underrated area for agentic products.
Most software is designed around:
happy path
Real businesses spend enormous amounts of time on:
"Something went wrong."
Examples:
- payment failed
- delivery delayed
- customer changed address
- supplier didn't respond
- invoice doesn't match
- product unavailable
- document missing
- employee didn't show up
- machine stopped working
- customer disputes the charge
Normal automation says:
IF X THEN Y
Agentic systems become interesting when:
X happened ↓ But the situation doesn't match the expected workflow ↓ Understand what happened ↓ Gather evidence ↓ Determine possible resolutions ↓ Choose or request approval ↓ Continue the workflow
Build around exceptions, not just happy paths.
21. Problem Area: Trust Networks
There are many Indian workflows where a transaction depends on relationships.
For example:
"Call the supplier you normally use."
The system may need to know:
- who responds
- who is reliable
- who negotiates
- who prefers calls
- who needs WhatsApp
- who has failed before
- who can handle urgent orders
This isn't just a database.
It is a relationship graph.
The opportunity:
What happens when an agent understands the relationships surrounding a business, not just the records inside its database?
This is a potentially deep direction for memory systems.
22. Problem Area: Reconciliation
Another powerful category is:
"Two systems disagree."
For example:
Invoice ≠ Payment Inventory ≠ Orders CRM ≠ Spreadsheet Supplier record ≠ Bank record Customer message ≠ Internal record
Humans often resolve these discrepancies manually.
This is an excellent agentic problem because the agent has to:
- gather evidence
- compare sources
- determine likely cause
- ask for missing information
- propose correction
- make the change
- leave an audit trail
That's much more interesting than:
"Summarize my database."
23. Problem Area: Decisions With Consequences
Another strong category is:
The agent is allowed to recommend, but should not always be allowed to execute.
Examples:
Low consequence
Create a draft email.
Medium consequence
Send a customer reminder.
High consequence
Issue a refund.
Very high consequence
Transfer money.
The interesting product question is:
How does software represent authority?
Think about:
AGENT │ ▼ UNDERSTAND │ ▼ EVALUATE RISK │ ┌────────────┼────────────┐ ▼ ▼ ▼ SAFE REVIEW BLOCK │ │ │ ▼ ▼ ▼ EXECUTE HUMAN STOP APPROVAL
This is one of the places where the next generation of agentic software can become substantially different from today's automation.
24. What NOT to Build
Before committing to an idea, ask:
Can Claude Code build most of this overnight?
If yes, reconsider.
Can Codex recreate the core product from a short specification?
If yes, reconsider.
Is the main innovation just connecting an API?
Probably reconsider.
Is the product essentially a chatbot over documents?
Reconsider.
Is the product a dashboard with an LLM summary?
Reconsider.
Is the only reason to use an agent that it sounds futuristic?
Reconsider.
Does the demo work entirely with fake data and no meaningful workflow?
Reconsider.
Does removing the sponsor API destroy the entire idea?
That's not necessarily bad — but ask whether the sponsor is solving a real technical requirement or simply being inserted for the prize.
25. What TO Build
Look for problems where the value comes from a combination of:
DATA + MEMORY + REASONING + WORKFLOW + HUMAN TRUST + REAL-WORLD ACTION
The more of these dimensions matter, the harder the problem becomes to solve with a generic coding agent.
26. A Simple Test for Your Idea
Before building, complete these sentences.
The user
We are building for __________.
The current problem
Today they have to __________ manually.
The hidden complexity
The difficult part isn't __________. The difficult part is __________.
The agent
The agent needs to remember / understand __________.
The action
The system eventually needs to __________.
The human
The agent cannot safely do __________ without __________.
The consequence
If the system gets this wrong, __________ happens.
The moat
A generic AI coding agent could reproduce our interface, but it would not automatically have / understand __________.
If you can't answer the last question, keep searching.
27. A Better Way to Think About Your Hackathon Idea
Don't start here:
"Which AI technology should I use?"
Start here:
"Who has a painful problem?" ↓ "What do they do today?" ↓ "Where does the workflow break?" ↓ "What information is missing?" ↓ "What does a human currently remember?" ↓ "What happens outside the computer?" ↓ "What decisions are risky?" ↓ "What should the agent be allowed to do?" ↓ "What happens if something goes wrong?" ↓ "Can we make the entire outcome better?"
Then choose the technology.
Not the other way around.
28. Where Our Sponsors Become Interesting
The sponsors should be treated as building blocks for the missing layers, not as the problem itself.
n8n
Think:
How does the agent connect decisions to real business operations?
n8n becomes the execution/orchestration layer.
Breeth
Think:
What does the agent need to remember beyond the current conversation?
Memory becomes business context rather than chat history.
Render Workflows
Think:
What work needs to survive beyond the current request?
Long-running execution, retries, parallel tasks and durable workflows become relevant. Render's current Workflows platform supports chained tasks, retries, managed queuing, state and executions up to 24 hours.
ElevenLabs
Think:
What happens when the user doesn't want to use a screen?
Voice becomes an interface into a real workflow, not simply a different way of displaying an LLM response. ElevenLabs Agents already support tools, workflows, knowledge, multilingual interaction and language detection, so the interesting hackathon problem should be what the voice interface enables, not merely adding speech.
Dodo Payments
Think:
What happens when an agent needs financial authority?
The interesting question becomes:
Who authorizes the action?
Under what conditions?
How does the system verify it?
What happens when the transaction is unusual?
29. Four Directions to Explore
You don't have to choose from these examples.
Use them as search directions.
🇮🇳 Fix a Broken Workflow
Look for an Indian workflow where humans are still the glue between fragmented systems.
Think:
- MSMEs
- field operations
- logistics
- healthcare administration
- agriculture
- commerce
- government processes
- local services
🧠 The Agentic Business
Look for a business where information exists but nobody has a complete picture.
Think:
- spreadsheets
- databases
- transactions
- conversations
- inventory
- customers
- payments
- operations
The question:
What would happen if the business had an intelligent operating layer rather than another dashboard?
⚙️ Agents That Don't Stop at the Answer
Look for work that naturally takes:
- hours
- days
- multiple actors
- external events
- retries
- approvals
The question:
What process needs an agent that can remain responsible for the outcome?
🎙️ Beyond the Screen
Look for people who currently interact with systems through:
- phone calls
- voice notes
- local languages
- physical documents
- in-person processes
The question:
What becomes possible when the interface adapts to the person instead of forcing the person to adapt to the software?
30. The Ultimate Hackathon Test
Before you submit your idea, ask your teammate:
"If Claude Code or Codex became twice as good tomorrow, would our product become irrelevant?"
If the answer is:
Yes
you may have built a feature.
If the answer is:
No — because our value comes from the workflow, proprietary context, persistent memory, physical-world interaction, trust, network, operational data, human relationships, or execution system around the model.
Now you're getting closer to a company.
31. The EmberGround Challenge
We don't want you to predict the future of AI.
We want you to discover where today's AI stops being enough.
Find the point where:
a model can reason, but somebody still has to coordinate.
Find the point where:
software has the data, but nobody has the context.
Find the point where:
the agent knows what to do, but isn't allowed to do it alone.
Find the point where:
the workflow cannot finish in one conversation.
Find the point where:
the computer ends and the real world begins.
And then build the missing layer.
Final Principle
Don't compete with Claude Code.
Don't compete with Codex.
Don't build something that becomes a feature of them tomorrow.
Use them.
Use them to build faster.
Use them to prototype.
Use them to write the infrastructure.
Use them to explore.
But spend your hackathon thinking about the thing around the model:
MODEL │ ▼ ┌───────────────┐ │ Your Problem │ └───────────────┘ │ ┌───────┼────────┐ ▼ ▼ ▼ Context Workflow Trust │ │ │ └───────┼────────┘ ▼ ACTION │ ▼ REAL WORLD │ ▼ OUTCOME
The goal isn't to build the smartest agent.
The goal is to find a problem where an agent can finally become useful enough to matter.
Build the layer that today's agents are still missing.