Looking for the most trusted design agency for AI companies? Book a call with Studio Maydit

AI Agent Activity Log Design: What Did It Send?

Summarize with AI

Good AI agent activity log design starts from the question your customer actually asks, and it is almost never whether the job ran. It is what the agent did for him today and whether anything needs his attention. So the screen he sees should be a feed of outcomes and exceptions he can scan in a minute, with the raw event log one click below it for your engineers.

This matters more for an agent than for any other AI product. A chat answer is read the moment it appears. An agent works while nobody is watching, so the activity screen is the only place a customer ever sees the work. If that screen is a list your team can read and your customer cannot, you have the oldest problem in product: you know your product and nobody else does.

Email sent, Success, and no names anywhere

Picture an AI sales agent, used here as an example. A five-person recruiting firm connects its inbox and its CRM, picks a list called Q4 Seed Founders, and lets the agent run outreach. The agent researches each contact, writes a first email, follows up, and stops when someone replies.

At the end of a Tuesday, the customer opens the Activity tab. It is a table with three columns: Event, Status, Time. Row after row reads Email sent, Success, 09:14:02. Then Email sent, Success, 09:14:07. There are 340 rows for that one day. Mixed in are Enrichment completed, Sequence step advanced and Webhook received. The only filter is a dropdown set to All events. Top right, a button reads Download events.

Nothing in the table says who an email went to. The recipient sits inside a row you have to expand, in a block of JSON, under a field called to_address. The subject line is not shown at all.

The prospect who wrote back on Wednesday

On Wednesday morning one prospect writes to the firm's founder directly. In this example his reply says it is the third email this week and that he asked to be taken off the list on Monday.

The founder opens Activity to see what went out. The search box matches event names, not people, so typing the prospect's surname returns nothing. He sorts by time and starts scrolling. Twenty minutes later he has expanded about forty rows and still cannot say whether the agent sent two emails or three. He clicks Pause all sequences. Then he sends you a Slack message with a screenshot of the angry reply.

Now the scene moves to your side. You open your admin panel, query the messages table by email address, and find all three sends in under a minute. The third went out because the removal request landed in a shared inbox the agent was not watching. You paste the three emails into Slack with a careful explanation. It is a good answer. It is also an answer only you could give, and the agent is still paused.

An event log answers the engineer's question

The table on that Activity tab is not badly built. It is an event log, and an event log is the right tool for the people who wrote it. It tells you whether each job ran, in what order, and where it failed. When something breaks at two in the morning, that is exactly what your team needs.

The customer is asking something else. He wants to know what the agent achieved, what it chose not to do, and what it is waiting on him for. None of those are events. Each one is a summary of many events, grouped around a person or a decision. A log cannot give him that by getting longer.

This is where most advice on agent UX goes wrong. It says to show everything, because transparency builds trust. A log of every action is complete, but complete is not readable. Three hundred identical rows hide the one row he needs as well as a locked box would. Measure transparency by how fast the customer finds his answer, not by how much you put on the screen.

It is also a different job from an audit trail. An AI audit interface serves the reviewer who arrives after a dispute and needs the full record behind a decision. The feed serves the customer who opens the tab every morning and has one minute before his first call.

What the Pause button costs you

In this example the agent did nothing a reasonable person would call wrong. It followed the rule it was given. But the customer could not see that, so from his side the agent misbehaved and he had no way to tell how badly. Pausing everything was the sensible move. Pausing is also how churn starts. A paused agent does none of the work the customer pays for, and a customer who has paused once checks the tab with suspicion every day after.

For a product-led company this shows up in activation. Measured on SaaS and product-led companies, activation runs 20 to 40 percent for most products and 40 to 60 percent for the best. A ten point improvement in activation typically drives a 15 to 25 percent increase in free-to-paid conversion. For an agent, activation is not the first run. It is the first week the customer leaves the agent running without checking on it. A feed he cannot read pushes that week further out, and some customers never get there.

It also changes how your product is read. Three hundred rows of Email sent look like a mail merge on a timer. The real work, the contacts the agent chose to skip and the drafts it held back, is in the database but not on the screen. A customer who cannot see the judgment assumes there was none, and the wrapper question comes up in his renewal call instead of your investor meeting. With the Series A bar for AI startups around 3.5 million in ARR (Carta, Q1 2026), the customers you already have are the part of that number you can least afford to lose.

The same rule holds on a marketing site. For Sathi, an affiliate platform for Shopify brands, the site we designed groups the product under headings like See Everything and Catch Affiliate Fraud, so a stranger meets what the product catches before the feature detail. Exceptions are the proof of judgment, on a website and inside a product.

The same Tuesday, rebuilt as a feed

Here is that day on a screen built for the customer. At the top, one line in plain type: Today the agent emailed 312 people, got 9 replies and booked 2 meetings. Under it sits a band called Waiting on you, with a count of 3. Each item is one sentence and one button. Two drafts mention pricing and need your OK, with Review drafts. One reply looks like a removal request, with Open thread.

Next comes a collapsed group labelled Skipped, 41. Opened, it reads: 41 contacts left out because they already have an open deal in your CRM, and it lists them by name and company. This is the line that shows the agent thinking. Below it sit the outcomes, replies and meetings, each one a person, a company and the last message in the thread.

The search box at the top reads Find a person or company. Typing the prospect's surname opens his page: every email the agent sent him, in order, with date and subject line. Under each one is a grey line that starts with Sent because, followed by the rule that caused it, such as Follow up after three days without a reply, step 2 of Q4 Seed Founders. The rule name is a link that opens the sequence, where the customer can change it. At the bottom of the page is a button reading Stop all contact with this person.

On that screen the Wednesday problem takes the customer under a minute. He finds the prospect, sees three sends and the rule behind the third, and stops contact for that one person. The rest of the list keeps running. The raw event log is still there, behind a small link on each person's page labelled View technical log.

Five changes to ship this week

  • Write the summary line first. One sentence on today's outcomes, in the customer's units: people contacted, replies, meetings, tickets closed, invoices chased. If your data cannot produce that sentence, fix that before any layout work.
  • Pull exceptions to the top. Anything held, failed, skipped or waiting on the customer goes into one band above everything else. Each item is a sentence with one button.
  • Make people searchable. Index the feed by the person, company or record the agent acted on, not by event type. Customers search for who, never for what kind of event.
  • Attach the cause to every action. Store which rule, step or instruction triggered each action, and show it as a link the customer can open and edit. That turns a complaint into a settings change.
  • Collapse the routine. Group identical successful actions into one line with a count and the names inside. Three hundred sends are one line, not three hundred.

Then test it with one customer. Ask him what the agent did yesterday and time how long he takes to answer from the screen alone. If it takes more than a minute, the feed is still a log. The agentic UX guide covers the confirmation moments that sit upstream of this screen, and if you would rather hand the work to a team, the ranking of UX design agencies for AI agent startups is a fair place to start.

How Studio Maydit works on agent screens

Studio Maydit is a product and web design studio for AI founders in the US, UK and Europe. On agent products we usually start with the screens a customer opens after the agent has run, because that is where he decides whether to leave it on. A fixed-scope project runs three to four weeks and ends with a diagnosis of what is leaking in the product, and for an agent that is often the activity tab. If your customers keep messaging you to ask what the agent sent, book a 30-minute call with Studio Maydit.

Frequently given answers

Sid, founder of Studio Maydit

Looking for something else?

Book a call with the founder.

A customer-facing activity screen should open with a one-line summary of outcomes, then a short list of exceptions that need the customer, then searchable results by person or record. Routine successful actions should be collapsed into counts. The raw event log can stay one click away for support and engineering.

An audit log is a complete record built for someone investigating a decision after the fact, such as a compliance reviewer. An activity feed is built for daily scanning by the customer who uses the agent. The feed summarises and groups. The audit log keeps every detail. Most agent products need both, on different screens.

Give skipped and held actions their own visible group with a count and a plain reason, such as contacts left out because they already have an open deal. List the names inside the group. Decisions not to act are often the clearest evidence that the agent uses judgment, so they should not live only in the database.

Usually not as the default view. Most customers check an agent once or twice a day, so a summary since their last visit plus exceptions as they happen serves them better than a live stream of events. A live view is useful during the first few runs, when the customer is still deciding whether to trust the agent.

Store the rule, sequence step or instruction that triggered each action, and show it under the action in plain words. Make that rule a link that opens the setting where it can be changed. This lets a customer fix the cause of a bad action himself instead of filing a support request.

About a minute for a normal day. A simple test is to ask a customer what the agent did yesterday and time how long the screen takes to answer it. If they need to scroll, expand rows or export data to find the answer, the screen is still an event log, not a feed.

Let’s chat about
what you’re building

Tell us where you’re headed, and we’ll scope the right plan for you.