In the last article, I built a working agent with EVE that helps users design cross-border e-commerce market-entry strategies using real market data fetched via the AIsa API.
But before letting Claude pile more complexity onto the project, it's important to design the agent first; otherwise, the code would quickly become incomprehensible.
Cross-border e-commerce is a complex domain, with different shipping countries, destination countries, platforms, deployable capital, and levels of experience; it's impossible to design one SaaS product that handles every seller's needs. Luckily, we have agents — they're supposed to handle diverse needs.
I've split the full build into several articles, and hopefully, in the end (dozens of articles later), we'll have an agent that can handle the complexities of shipping products overseas.
In this second article of the series, let's tackle one specific problem:
How should an agent know what the user needs?
Before we dive into the design and implementation, let’s see the implemented interview workflow first:
When I started thinking about how to let the agent get to know the user, two methods came to mind: 1) a form; 2) a user interview.
The problem with forms is that they’re pre-configured by humans, and to cover all the diverse needs, they’d require a lot of questions with manual text entry. That’s both boring and time-consuming for users.
So I chose the second method: a user interview led by the agent. The goal is to use multiple-choice questions as much as possible, with each next question generated on the fly based on the user's previous answers. In this article, we'll design and implement this method in our agent.
To achieve this, we roughly need the following:
A mechanism to store a user’s profile after the interview.
An interview skill or workflow.
A GenUI system that produces UI components dynamically based on the user’s previous answers. Luckily, the default ask_question tool provided by the EVE framework already provides a GenUI feature for TUI.
The tech stack
How to store a user’s profile
We need to answer two questions:
Where should we store the profile, and in what format?
How should the agent load the profile into its context?
First, let's clarify the scope of this agent: it runs locally, for a single user. This means we don't need to worry about cloud storage or cross-tenant auth, which simplifies the architecture a lot and lets us focus on the fundamentals of the agent.
After a careful review process (interrogating EVE's docs with agents), I decided to store the profile as JSON with a Zod schema:
import { z } from "zod";
export const Profile = z.object({
schemaVersion: z.literal(1),
updatedAt: z.string(), // ISO timestamp
facts: z.record(z.string()), // key -> value, model-chosen keys
notes: z.string().default(""), // freeform prose the model can append to
});This gives us the following benefits:
Compatibility: the model already speaks JSON, so it’s easy to drop into a conversation.
Flexibility: partial updates are trivial; the profile file is likely to grow each turn, and the agent may also need to modify existing content to match what it just learned about the user.
Safety: with a Zod schema in place, a malformed file fails loudly instead of silently poisoning the context.
The EVE agent runs in its own sandbox, which means the files can stored inside it and EVE provides the agent with built-in ops to manage the sandbox (bash, read_file, write_file, glob, and grep), user-defined tools can also target this sandbox, we’ll use this feature to copy the written files out of the sandbox for easier review.
Cool, we've figured out how and where to store the profile file — but how should we let the agent load it into context?
Important concepts
Session: Starts with the first message sent to your agent. EVE creates durable sessions, meaning a session only ends if you explicitly renew it, if it expires after a set amount of time, or if an unrecoverable error happens. But it seems like in dev mode, eve agent always start a fresh session, I couldn’t find relevant info in the official doc, but this is the behavior I observed with the agent.
Turn: You say something, the agent responds - that’s a turn.
Step: An action the agent takes while composing a response, including but not limited to thinking, searching, tool-calling, and replying.
A session contains many turns, and a turn contains many steps.
In EVE, you generally have three ways to load things into the model’s context:
session.started: Loads context at the start of a session and keeps it cached; useful if the user’s profile doesn’t change turn by turn.
turn.started: Loads context at the start of each turn; this allows profile edits to take effect mid-session.
instructions.md: The good old instructions that rely on model cooperation.
Since we’re building the agent-led interview process right now, the only things the model needs to know are:
How to conduct an interview: this should be a skill.
Interview-specific context: the user’s answers to previous questions.
The choice among context-loading techniques touches on an important question in agent-building: when to rely on rigid programming. In our case, I'd still rely on the more rigid approach: turn.started, because I’d like to make sure new users always get the interview before they proceeding to ask specific questions.
The interview workflow
Alright, we’ve figured out the profile format and where to store it; let’s move on to the next part: getting the agent to conduct the interview. We need to solve the following questions to give our agent this capability:
How should we implement the interview workflow in the EVE framework?
Which AIsa endpoints should we use to create tools for the interview?
Implementation
Again, there are different approaches to implementing the workflow:
Pure skill: We package the workflow into a SKILL.md and the relevant actions into scripts.
Skill + tools: We put SKILL.md into the agent/skills folder, but define the tools the skill uses inside the agent/tools folder.
Instructions + skill + tools: We also modify the agent/instructions.md file to let the agent know about the interview skill.
One thing worth noticing is how EVE advertises tools defined under agent/tools versus those defined within a skill folder:
agent/skills: EVE scans this folder and exposes the skill descriptions to the model.
agent/tools: EVE advertises tools in this folder to the model, whether or not the skill is loaded.
The difference between these two approaches likely comes down to tool-discovery stability, context cost per turn, and design preference (monolithic vs. orthogonal). These are my own interpretations, take it with a jar of salt.
At this point, the agent can conduct dynamic interviews that generate the next question based on the user’s previous answers (Hooray!). However, there are two issues we need to address to make the experience better:
How to view the generated artifacts?
How to improve the interview quality?
The first is EVE-related; the second is AIsa-related (it requires richer context, hence more data, hence AIsa).
Viewing the generated artifacts
An agent built with EVE runs in an isolated sandbox, which means it can only read and write files within that sandbox — it cannot directly operate on your local folders. The most straightforward solution I can come up with is to define an export skill, so the agent can export the generated artifacts to a place the user can easily view. EVE actually provides an agent/connections folder where you can define external MCP connections, but I'll leave that implementation to later articles so we can focus on this interview flow.
Improving the interview quality
The core goal of this interview flow is to give the agent a way to learn deeply about the user's needs; it should identify what types of information are most useful for a specific user, given their unique background and constraints.
Beyond gathering what the user says, the agent should also help users discover the things they think they know but actually don't — as Hemingway put it, these are the things that most often trip us up. Imagine a user saying they're not too worried about compliance, and the agent throws out a few quick questions based on live data fetched through AIsa to check whether the user actually knows what they're talking about. Would this be bad UX? I'm not sure, but it's certainly fun.
This also touches on a philosophy of agent-building: do you want a pure executor, or a knowledgeable strategist who pushes back to help you understand things more deeply? Both are fine, but in situations with real-life consequences, I'd prefer the latter.
Here are the endpoints I found on AIsa that could help:
Keyword popularity data: Verifies claims like "xxx is booming/dying/seasonal."
Search volume data: Verifies claims like "my keyword gets tons of searches."
Google SERP results: Verifies claims like "everyone buys on xxx."
I used these AIsa endpoints to build a quick-check feature into the interview flow. The idea is to let the agent run quick little quizzes that test the user's knowledge against the live situation, helping them uncover potential blind spots.
Reflection
Okaaaay! We’ve built a not-perfect-but-works-just-fine interview workflow into our agent!
A quick recap of what we did:
Chose JSON with a Zod schema as our user profile format.
Implemented two new skills: interview + export.
Composed AIsa endpoints into a quick-check feature.
Implemented the interview workflow!
Drank lots of coffee.
To be honest, there are already many endpoints on AIsa, and with the upcoming Similarweb collaboration, there will be more. There must be a much better way to implement the quick check feature by combining endpoints differently, but let's leave that to later articles. What we really need is a tool — or simply a script — to do semantic search across all these endpoints; it's not practical to go through them manually and figure out how to compose them.
But hey, it should be fun to build out such a tool in the next article — it would help us easily find the best possible ways to use all the capabilities on AIsa. Just imagine: you describe a goal, and back comes a list of recommended endpoints with real response data and a composition guideline. That would be so cool.
See you next article! And don’t forget to drop a subscribe, it’s free ;)