San Francisco · Pre-launch party1:35
Before the launch
A room full of builders, a first look at neatlogs, and a conversation about making agents reliable.
View original postWork at
We build the tools that help teams work out what went wrong and make the next run better.
- 12 Angry Devs · Night 050:22
Bring your demo. Expect opinions.
A glimpse of the developer community we’re building with. Real demos and plenty to talk about.
View original post 
A conversation before the launch
Ideas, shared in person
A demo worth discussing
Show the work. Hear the room.
- Bengaluru · On-site, day one0:29
Same team. Same room.
Usually a grid of faces. Sometimes a day together in Bengaluru.
View original post - Ajay’s launch diary · 011:06
The launch is the experiment
Ajay on the bets behind the launch, and why we’re showing the work as we go.
View original post 
Time together, heads down
We’re fully remote
Our team works across the US and India. Ajay splits his time between Gurgaon and San Francisco, where many of our customers are.
We write decisions down so work can keep moving across time zones. We get together when being in the same room helps us plan, build, or get to know one another better.
Write it down
The decision and its reasoning should be available to the person who wasn’t in the call.
Talk to the user
Everyone gets close enough to customers to understand what went wrong and why it matters.
Overlap, not office hours
We share 4 hours a day. How you arrange the rest is up to you.
Meet in person
We hold regular offsites to plan, make things, and spend time together.
How we work
See the whole problem
The trace tells us what the agent did. A customer or support teammate can tell us why that outcome was wrong.
Have taste
“Technically works” isn’t the end of the conversation. We care whether a fix is clear, useful, and easy to trust.
Stay for the result
We ship small changes and check what happened. If the evidence changes our minds, we change the product.
Room to take ownership
You can improve things beyond your job description. Get context from teammates, agree on a direction, and follow through until the change helps a user.
Notice it. Own it
If you spot something rough, you can do something about it. Make a call, pull others in when you need them, and finish the job.
Principle 01 / 05
Things change here
Priorities can shift from one week to the next. The roles are broad, and what you’re working on six months from now may look different from the listing.
If that sounds like a problem you’d enjoy, keep going.
8 open roles
- Engineering
Lead Software Engineer
RemoteFull-timeBuild the systems that let teams investigate agent failures quickly, reliably, and together.
- Engineering
Software Engineer
RemoteFull-timeBuild the backend features and integrations that help teams make sense of agent runs.
- Engineering
AI Engineer
RemoteFull-timeMake messy agent behavior easier to understand, test, and improve.
- Design
Product Designer
RemoteFull-timeDesign how people see, understand, and fix agent behavior together.
- Design
Design Engineer
RemoteFull-timeDesign and build the interface where teams understand and improve their agents.
- Marketing
Content & Social Media Marketer
Remote, IndiaFull-timeTurn what we’re learning about AI agents into stories, explanations, and conversations people want to spend time with.
- Sales
Founding Salesperson
RemoteFull-timeTurn interest in neatlogs into customers, and build the sales motion while doing the selling yourself.
- Growth
GTM Engineer
RemoteFull-timeBuild the systems that help the right teams discover neatlogs, get value from it, and keep moving.
It started with an agent stuck in staging.
Ajay was building a support agent at VWO. It followed its instructions and still gave customers the wrong outcome.
Working out why meant piecing together traces, screenshots, Slack threads, and meetings. The agent stayed in staging for months.
Engineers could see what the agent did. The people who knew what it should have done were somewhere else.
He built neatlogs to bring the evidence and those people into the same workflow, from failed run to reviewed fix to verification in production.
Read Ajay’s note on why we started