DEV Community

anusha
anusha

Posted on

I Built an SMS Quiz Agent That Remembers Each Turn

I wanted a simple way to show how Telnyx Edge Compute can support a conversation that lasts longer than one request.

An SMS quiz is a good example because the state is obvious.

If I text start, answer question one, then answer question two, the system has to remember where I am. It needs to know my score, the current question, the correct answer, and whether the next question should be easier or harder.

The Telnyx code example is here:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/multi-turn-sms-quiz-agent

The end result is a quiz you can answer over SMS. Text start, reply with A, B, or C, and the quiz keeps going until the final score.

The Idea

The quiz teaches Edge Compute concepts through short multiple-choice questions.

Instead of asking questions in abstract terms, the prompt pushes the model to use concrete examples:

  • storage units
  • lockers
  • mail and delivery
  • keys
  • filing systems
  • rooms and spaces
  • saving and retrieving items

That makes concepts like durable state easier to picture.

For example, a StatefulActor can be explained like a storage unit for one sender. You leave the score and current question there, come back on the next SMS, and the data is still there.

What The Sample Does

The flow is:

text start
receive Q1
answer A, B, or C
receive feedback
receive Q2
repeat until Q5
receive final score
Enter fullscreen mode Exit fullscreen mode

Behind that simple SMS flow, the sample uses:

  • Telnyx Edge Compute
  • the Agent SDK
  • one StatefulActor per sender
  • Telnyx Messaging
  • Telnyx Inference
  • actor-local SQL for event history and webhook idempotency

The code is Node.js and TypeScript.

Why The Actor Matters

SMS messages arrive as separate webhook events.

Without durable state, each message looks isolated. The system sees B, but it does not automatically know which question that answer belongs to.

The actor solves that.

The sample routes each sender phone number to a stable actor name. That actor stores:

  • phase
  • score
  • difficulty
  • turn number
  • current question
  • current answer
  • sender and recipient phone numbers

So when the user sends B, the actor can retrieve the current question and grade the answer in context.

How Difficulty Adapts

The quiz starts on easy.

If the user answers correctly, the code moves difficulty up:

easy -> medium -> hard
Enter fullscreen mode Exit fullscreen mode

If the user answers incorrectly, the code moves difficulty down or keeps it easy.

The model helps generate and grade questions, but the adaptation rule is controlled by code. That keeps the quiz predictable.

The Question Style

The question prompt asks for one JSON object with the question, answer, and hint.

The question itself has three choices on separate lines:

Q2/5 (easy)
What is durable state most like?
A) A saved item in a locker you can open later
B) A message that disappears as soon as it is sent
C) A random address that changes every time
Enter fullscreen mode Exit fullscreen mode

The incorrect answers are supposed to be plausible. That matters because the quiz should test understanding, not just make the right answer obvious.

Running It

Start with the code sample:

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/multi-turn-sms-quiz-agent
npm install
Enter fullscreen mode Exit fullscreen mode

Then run:

npm run typecheck
npm run types
npm run ship
Enter fullscreen mode Exit fullscreen mode

Set your Telnyx Messaging Profile webhook to the deployed function, then text start to your Telnyx number.

You need a Telnyx API key and an SMS-capable Telnyx number. The sample uses the Telnyx Edge binding in the function code, so API credentials are not hard-coded into the message handling logic.

Why I Like This Example

It is small, but it shows the core pieces of a stateful SMS agent:

  • route each user to their own durable state
  • acknowledge inbound webhooks quickly
  • do slower AI work in the actor queue
  • save enough state to continue on the next message
  • send the next SMS from the same workflow

That is the pattern I would reuse for many SMS experiences where the user needs to answer one step at a time.

Resources

Top comments (0)