Building EduVetta: an AI tool for the parts of teaching nobody signed up for

Aaditya Dagar — Mon, 21 Sep 2026 15:35:25 +0000

I've spent the last few months building EduVetta, a small SaaS product for teachers. I want to write about what it does and why, without the usual "we're revolutionizing education" framing, because honestly it's a fairly narrow tool solving a fairly narrow problem.

The problem, as I understood it

Teachers spend a lot of time on tasks that are adjacent to teaching but aren't teaching: writing up what was covered in class, formatting a test, chasing down students who missed a lecture, marking a stack of submissions. None of this is hard, exactly. It's just repetitive and it eats time that could go elsewhere.

I talked to a handful of teachers before building anything, and the recurring complaint wasn't "I need AI in my classroom." It was closer to "I keep doing the same clerical task every week and it's tedious."

What we built

EduVetta has four main pieces, and they're deliberately simple:

Lecture and board notes. A teacher records a lecture or uses a digital board. The platform generates a summary and saves the board notes as a PDF, then sends both to the class Telegram channel. This replaces manually writing a recap message after every class.

Question paper generation. You give it a source, a topic description, a YouTube link, an uploaded PDF, or a spoken request, and it drafts a paper with marks and an answer key. You still review and edit before publishing. It's a first draft generator, not an autopilot.

Assignments. One link, no student account needed. Submissions come back in a list rather than scattered across email or WhatsApp.

Quiz games. Same input options as the question generator, but output as something playable rather than a static paper.

Where it's genuinely useful vs where it isn't

Objective grading (multiple choice, fill in the blank) is instant, which is the clearest win. Subjective answers still need a human, and we didn't try to automate that judgment call. I think that's the right line to draw for now, not because the model couldn't attempt it, but because grading written reasoning is exactly the kind of task where a wrong automated answer does real damage to a student.

Students don't need an app or login, they enter a name, roll number and batch. That was a deliberate choice to lower friction, even though it means less structured data on our end.

What I'd still call unfinished

The voice-to-question-paper flow works better for some subjects than others. Anything heavy on diagrams or equations needs more manual cleanup than plain text topics. We're also still figuring out the right defaults for quiz difficulty so teachers aren't stuck tuning settings every time.

If you want to see the actual product rather than take my word for it, there's a free tier with no card required: eduvetta.com

Happy to answer questions about the stack or the AI generation pipeline in the comments if anyone's curious.

Your agent passed every test and still broke in production

Aaditya Dagar — Thu, 20 Aug 2026 11:54:37 +0000

Code review stops at deploy. For a normal service that is mostly fine, because the code
that shipped is the code that runs. For an agent it is not, because the decisions it makes
after deploy were never in the diff.

Here is what actually breaks, in the order we keep running into it.

1. The demo exercises one path

A demo is a prompt going in and a good answer coming out. Production is that path plus
every path around it. The tool call that returns a 500. The one that times out after the
first of three steps. The response that parses on Tuesday and does not on Wednesday because
an upstream field became nullable.

None of those appear in a recording. All of them appear in week two.

2. Retries you did not write

Most SDKs and agent frameworks retry internally. That is usually good for reliability and
terrible for two things.

The first is cost. A malformed response can trigger a silent second call, and at volume
that becomes a real percentage of the bill that never shows up in a token report. If your
dashboard tracks tokens but not call count, you cannot see it at all.

The second is side effects. A retry on a read is free. A retry on something that sends,
charges, or writes to a downstream system is not. If the action is not idempotent, the
retry is a second real action.

Instrument call count separately from token count. It is a small change and it usually
finds money.

3. No compensating action

Draw the happy path for a three step tool sequence. Now draw what happens when step two
times out after step one succeeded.

Most designs have no answer. The agent either retries the whole sequence, repeating step
one, or it stops and leaves the system half changed. Both are worse than failing cleanly at
the start.

The fix is not clever. Decide, per action, what undoes it, and write that down before the
agent ships. If an action cannot be undone, it needs a gate.

4. Everything is treated as equally reversible

This is the one that decides how much autonomy an agent can safely have.

Sort every action the agent can take into two buckets. Reversible: reading, ranking,
drafting, generating an audit trail, setting an internal status. Irreversible: sending a
message to a person, moving money, triggering a verification, deleting a record.

Let the agent act freely in the first bucket. Put a human gate on the second. That single
split does more for shippability than any amount of prompt tuning, because it means a bad
decision costs a retry rather than a phone call.

5. Success is measured as completion

If the only metric is how many cases the agent closed, you have created an incentive to
guess. An agent that closes 95 percent and quietly gets 4 of those wrong is worse than one
that closes 80 percent and hands back the rest with a reason.

So measure abstention. How often does it stop? Is it stopping on the right cases? A model
that knows what it does not know is a model you can put in front of a customer.

6. Observability tells you about last Tuesday

Traces are necessary and they are not sufficient. A trace tells you what the agent did. It
does not stop the thing from happening again tomorrow.

If a class of action needs to never happen, that belongs in a policy layer that can reject
the action before it executes, not in a dashboard someone reads on Thursday.

What we do before shipping one

Every action labelled reversible or not, in writing
Idempotency keys on anything with a side effect
A defined compensating action for each step of a multi step sequence
Call count and token count on separate graphs
Abstention rate tracked as a first class metric
A policy check that can refuse an action, sitting outside the model

None of it is exotic. It is the same discipline you would apply to any system that can act
on its own, which is what an agent is, even when it is wrapped in a chat box.

Written by Aaditya Dagar. I build agent systems at
Profit Agentz, mostly for fintech, recruitment and
operations teams.

DEV Community: Aaditya Dagar