WEBVTT
00:00:00.160 --> 00:00:10.240
A lot of the agents and workflows that we build are mostly focused around mission critical multi-step processes that often involve different kinds of personas.
00:00:10.720 --> 00:00:16.879
So they're not agents for just end-to-end knowledge work that usually starts and ends with a person.
00:00:17.280 --> 00:00:19.280
They're usually multi-step processes.
00:00:19.359 --> 00:00:29.679
So think of things like invoice processing, end-to-end invoice processing and correction, or diligence reporting, or different kinds of multi-step monitoring systems.
00:00:30.000 --> 00:00:33.200
Most podcasts talk to founders after the story is already written.
00:00:33.359 --> 00:00:36.960
When the latest trade is announced, the product has shipped and the narrative is clean.
00:00:37.280 --> 00:00:40.719
We wanted to find out why they decided to take the founder leap in the first place.
00:00:40.880 --> 00:00:44.719
What idea captured their imagination and how they handle the pressure to build?
00:00:44.880 --> 00:00:45.840
Welcome to First Commit.
00:00:46.079 --> 00:00:46.960
I'm Laura Hamilton.
00:00:47.280 --> 00:00:50.159
I'm Elie Lone and we're investors at Federal Capital.
00:00:50.320 --> 00:00:53.520
We spend a lot of time with technical founders who are on the cutting edge.
00:00:53.679 --> 00:00:57.520
If you're thinking about what it's like to start a company in the AI era, this one's for you.
00:00:57.759 --> 00:00:58.799
This is First Commit.
00:00:59.039 --> 00:01:00.240
Let's get into it.
00:01:01.359 --> 00:01:03.920
Today we are chatting with Maya from Thread AI.
00:01:04.079 --> 00:01:07.920
Maya is the co-founder and CTO working on AI native orchestration.
00:01:08.079 --> 00:01:08.799
Welcome, Maya.
00:01:09.040 --> 00:01:09.840
It's great to be here.
00:01:10.079 --> 00:01:11.120
It's great to have you.
00:01:11.359 --> 00:01:17.120
So you came up through Goldman Sachs and built the digital subscriptions platform at the New York Times before landing at Palantir.
00:01:17.200 --> 00:01:23.519
It would be great if you could touch on the thread connecting all those experiences and when you knew that you wanted to branch off on your own.
00:01:23.920 --> 00:01:32.239
Yeah, so I've spent, I want to say, the majority of my career working in across various regulated spaces and enterprises.
00:01:32.400 --> 00:01:42.000
So yeah, when I started my career at Goldman Sachs, I was primarily an infrastructure backend engineer, building software for various business divisions and prime brokerage and futures trading.
00:01:42.079 --> 00:01:49.519
So there was always this emphasis on security and data governance and understanding basically how to build software at scale.
00:01:49.760 --> 00:01:51.120
And that's been the theme.
00:01:51.280 --> 00:01:57.840
So even when I went to go work at the New York Times, I spent a good chunk of my career building out their payment systems.
00:01:57.920 --> 00:02:06.640
And so working directly with auditors and making sure that the infrastructure that we built is PCI compliant among other types of compliance.
00:02:06.799 --> 00:02:17.120
And similarly, the work that we've done at Palantir has been working with not just large government agencies like the defense, but also working with other large enterprises.
00:02:17.280 --> 00:02:23.120
And that's been the theme, whether we're building AI native software or other kinds of software.
00:02:23.280 --> 00:02:26.319
I spent a lot of my career working in these regulated spaces.
00:02:26.479 --> 00:02:45.840
So understanding their needs, and that has really helped shape the experience of how we think about building software at ThreadAI, understanding enterprises from basic principles and building software that fits their needs, as opposed to building a proof of concept and then trying to retrofit enterprise features into it.
00:02:46.159 --> 00:02:46.800
Yeah, that's great.
00:02:46.879 --> 00:02:51.680
We'll definitely get into how you're focusing on AI orchestration and what that means at Thread.
00:02:51.840 --> 00:02:55.280
But before that, I would love to dive deeper into your work at Palantir.
00:02:55.439 --> 00:03:01.680
So as you mentioned, you were building infrastructure that ended up in the hands of the DoD, but didn't get the clearance to see your work deployed.
00:03:01.759 --> 00:03:08.400
I would love to hear more about that story and kind of what that did psychologically to maybe fuel the fire.
00:03:08.719 --> 00:03:10.560
It was definitely a very interesting experience.
00:03:10.639 --> 00:03:14.400
So when I joined Palantir, I was not yet, like you mentioned, a US citizen.
00:03:14.639 --> 00:03:21.840
There were many cases where I had to build a lot of software, and I oftentimes would not see how it would get deployed in the field.
00:03:22.000 --> 00:03:28.080
And I think the main thing that has enforced is obviously working in a team with high trust.
00:03:28.240 --> 00:03:31.439
So I spent a lot of time working with my now co-founder, Angela.
00:03:31.520 --> 00:03:40.159
At the time, she had the clearance and access to the problems at the edge, and it really helped forge this strong work relationship.
00:03:40.319 --> 00:04:00.159
But also the main thread here is when you're building software, especially infrastructure, there's certain kinds of reliability guarantees and feature sets that we have to make sure exist so that you can have the peace of mind where knowing regardless of where your software is deployed, it is functioning according to whatever invariance that you've set.
00:04:00.319 --> 00:04:05.759
So there is a certain quality and certain bar that you have to make sure that each feature holds.
00:04:05.840 --> 00:04:08.080
And it's almost like building like a database.
00:04:08.319 --> 00:04:33.680
You can't simply assume that people are going to retry certain things or people are going to assume certain DevX or UX because you have to make sure that the software, however way it is used, it is always acting deterministically, or it is always surfacing the kinds of metrics and enforcing the certain feedback loops where it is behaving the same way whether it is deployed in low side or deployed on the moon or deployed wherever it is deployed.
00:04:33.920 --> 00:04:34.079
Okay.
00:04:34.240 --> 00:04:42.639
So then when you were at Palantir working with Angela, how did you know that one, she was the right person to work with, and two, that it was time to leave?
00:04:42.959 --> 00:04:46.000
We spent a lot of time working together on a lot of different projects.
00:04:46.160 --> 00:04:47.680
So she's also very technical.
00:04:47.839 --> 00:04:49.839
Her background is also engineering.
00:04:50.000 --> 00:04:55.519
And the interesting part is a lot of I think our skill sets is a nice Venn diagram.
00:04:55.680 --> 00:05:00.240
Whereas my background has been mostly spent in distributed systems and infrastructure.
00:05:00.399 --> 00:05:04.879
Her background has been mostly spent in working with data and intelligence systems.
00:05:05.040 --> 00:05:22.480
So that kind of like gave us a nice complete skill set of the things that you need to be able to build the kinds of software that you want to build across working closely with data and understanding data and working across infrastructure and deploying that in various kinds of modalities.
00:05:22.639 --> 00:05:25.519
And I think working at Palantir, we've learned a lot.
00:05:25.759 --> 00:05:33.199
You get access to crazy problems that maybe other software companies would not put engineers at the front line of.
00:05:33.360 --> 00:05:42.879
Oftentimes, a lot of software companies have many layers of abstractions away where there are the solutions architects and the different operational layers and the different kinds of testing.
00:05:42.959 --> 00:05:47.439
Whereas Talentier, they take bets on very strong autonomous software engineers.
00:05:47.600 --> 00:05:53.040
And oftentimes you'll find yourself meeting people that normally you wouldn't at any other tech company.
00:05:53.199 --> 00:05:57.040
And to your question around when did we think it was time to leave?
00:05:57.199 --> 00:05:59.839
I think that was around spring of 2023.
00:06:00.160 --> 00:06:02.160
And the market was very exciting.
00:06:02.240 --> 00:06:07.199
There was a lot of exciting things happening across different kinds of ML and language models.
00:06:07.360 --> 00:06:12.560
And I think we had a lot of conviction, knowing that we've known how to work together.
00:06:12.800 --> 00:06:17.759
For us, that was almost more important than sometimes like the specific idea.
00:06:17.839 --> 00:06:21.680
Because like we knew that whatever it is that we built, we know how to make it work.
00:06:21.839 --> 00:06:24.560
We spent a lot of time building horizontal infrastructure.
00:06:24.800 --> 00:06:31.519
And I think being excited about working together was almost, I would say, like more important than what idea we had at the time.
00:06:31.759 --> 00:06:39.920
Was there anything psychologically or EQ test that you ran just to ensure the partnership would be what you had in mind?
00:06:40.399 --> 00:06:45.519
I think I would say working closely together for over four years kind of like gave that.
00:06:45.759 --> 00:06:57.040
It's very challenging to take these large bets with someone that you've just met, mostly because you will be put in very difficult situations and oftentimes situations that will test your character.
00:06:57.199 --> 00:07:13.680
So knowing how you work very intimately with someone and making sure that your communication skills line up, whether it is how you how you surface disagreement or how you resolve conflicts or how knowing which problems and which hills to die on.
00:07:13.759 --> 00:07:21.199
And uh, and as long as I guess like uh co-founders know how to work that out, I think that is the most important thing.
00:07:21.439 --> 00:07:31.439
But I think, yeah, a lot of it uh came, I guess like for us, we were lucky because we were tried and tested already in previous kind of like lives, and that gave us kind of like the data points.
00:07:31.600 --> 00:07:49.839
But again, that's not to say that starting a company isn't a completely different beast, but at least you'll have kind of like a lot of the data points already if you've worked with someone that closely and within that capacity, which is different also from in some cases folks will think that they if they start a company with their friends, they know their friends and nothing really that's a very For sure.
00:07:49.920 --> 00:07:58.319
And it I mean it's very daunting to leave a safe job that you're enjoying and you're still learning a ton, and to start a company with someone but you don't know what you're starting yet.
00:07:58.560 --> 00:08:06.800
When you're thinking about brainstorming, how did you seek validation about early proof points that thread would be what it is today?
00:08:06.959 --> 00:08:09.120
Or maybe you started with a different idea.
00:08:09.519 --> 00:08:13.839
We were fortunate in that I would say we haven't pivoted from when we started.
00:08:14.000 --> 00:08:20.720
So a lot of the time that we spent at Pound Tier was mostly building ML ops, to building model training, model inference, model evaluation systems.
00:08:20.879 --> 00:08:30.240
And we knew that we did not want or could not even build whatever it is that we build at Pound Tier for various different reasons, but also that was not the space that we wanted to be in.
00:08:30.399 --> 00:08:33.519
We were very interested in everything that happened downstream of that.
00:08:33.679 --> 00:08:40.559
So everything downstream of ML ops because we knew that models will continue to be more ubiquitous, more available.
00:08:40.720 --> 00:08:46.320
There will be a lot of interesting things, the model will continue to improve, there will always be like model drops every week.
00:08:46.639 --> 00:08:55.120
But the hypothesis was that enterprises will still have very unique challenges operationalizing these models for different kinds of reasons.
00:08:55.200 --> 00:08:58.080
And the models cut across infrastructure and application layer.
00:08:58.240 --> 00:09:06.559
They they now are mixing and matching multimodality, which, like in previous worlds, that was that was almost like completely separate infrastructures.
00:09:06.799 --> 00:09:10.799
And we've really admired what some of the orchestration companies have done.
00:09:10.960 --> 00:09:18.240
So around 2023, we knew that companies like Temporal and Conductor have solved for a lot of the durability and core orchestration problems.
00:09:18.320 --> 00:09:24.799
But at the time, we noticed that they haven't solved for the non-determinism that comes with AI models.
00:09:25.039 --> 00:09:27.679
So we thought there's a lot of market for in that space.
00:09:27.919 --> 00:09:34.080
And we were also really inspired by that tool former paper that came out of Meta, I think early 2023.
00:09:34.240 --> 00:09:38.559
And that but that paper was mostly focused around language models and giving them access to tools.
00:09:38.720 --> 00:09:50.720
We knew that enterprises were not going to train specific on specific APIs, but we thought a lot of the ideas behind that paper were very interesting, almost interesting enough for someone to quit their job.
00:09:50.879 --> 00:09:59.360
And I think that paper was almost like the inception of a lot of what we see right now: things like function calling, tool calling, MCP and agent.
00:09:59.519 --> 00:10:03.519
And that's been kind of like that space that's now getting a lot of traction.
00:10:03.679 --> 00:10:08.240
But we knew basically to be able to do that for a large enterprise.
00:10:08.399 --> 00:10:17.360
And not understanding like the enterprise ecosystem, which oftentimes has a lot of legacy systems, has a combination of vertical software, has different kinds of like data problems.
00:10:17.519 --> 00:10:24.080
Being able to build these kinds of agents that meet enterprise guarantees is a very hard problem.
00:10:24.399 --> 00:10:28.240
But and usually hard problems have like decent markets.
00:10:28.480 --> 00:10:31.440
And I would love to touch on what types of agents you're building for the enterprise.
00:10:31.519 --> 00:10:41.279
Because I can imagine there's some use cases where you're seeing parallelism between one enterprise and another and more software, but I can imagine a lot of use cases could be more services heavy.
00:10:41.360 --> 00:10:44.879
So I'm curious how you balance the services versus software approach at thread.
00:10:45.200 --> 00:10:52.559
We've learned a lot and again, how what works well with the forward deployed, what doesn't work well with the forward deployed model.
00:10:52.799 --> 00:10:58.080
And for us, when we started, it was always we knew we always wanted to build a product and a platform.
00:10:58.320 --> 00:11:02.639
But obviously, there is always kind of like some customization that has to happen.
00:11:02.799 --> 00:11:11.279
But oftentimes, enterprises are also, if you teach them and they're they are willing to work on these specific customizations.
00:11:11.360 --> 00:11:19.360
So you can always kind of like sometimes push back on some of these specific bespoke customizations and have the customer own a lot of that.
00:11:19.600 --> 00:11:29.759
A lot of the agents and workflows that we build are mostly focused around mission critical multi-step processes that often involve different kinds of personas.
00:11:30.159 --> 00:11:36.399
So they're not agents for just end-to-end knowledge work that usually starts and ends with a person.
00:11:36.720 --> 00:11:38.799
They're usually multi-step processes.
00:11:38.879 --> 00:11:53.120
So think of things like invoice processing, end-to-end invoice processing and correction, or diligence reporting, or different kinds of multi-step monitoring systems, or triaging workflows that involve mechanics in the field.
00:11:53.360 --> 00:12:08.879
And oftentimes you these workflows have data capture, so things from physical systems, and they often will require you to run large workloads asynchronously, and then they'll sometimes require an investment in a human of the loop.
00:12:09.039 --> 00:12:12.240
So usually a person who has domain expertise.
00:12:12.320 --> 00:12:15.840
So they're not necessarily the person, the builder, the person who created the workflow.
00:12:16.000 --> 00:12:21.679
They're not necessarily like that kind of persona, but they oftentimes are the domain experts.
00:12:21.840 --> 00:12:31.919
So let's say you're it is an insurance claim processing workflow, they would be the ones who have go or no go and around the outputs of the models.
00:12:32.080 --> 00:12:40.639
So they basically would stop when the workflow stopped and their feedback is solicited, they would know whether to correct it or deposit or to reroute it.
00:12:40.799 --> 00:12:50.159
And then basically a lot of these workflows oftentimes will push out data to the customers' things, whether it's their own data lake or like some kind of notification system.
00:12:50.639 --> 00:12:57.120
And our infrastructure makes it very easy to swap in and out models to create.
00:12:57.279 --> 00:13:03.600
We've invested a lot in the separation of data and compute, so creating a very interesting context layer.
00:13:03.840 --> 00:13:12.240
So we handle a lot of the data movement that comes with that data entry and eviction and help enterprises basically connect that to their systems.
00:13:12.480 --> 00:13:18.799
So oftentimes these workflows are long-running, multi-step, and involve different kinds of personas interacting with them.
00:13:19.120 --> 00:13:19.519
Got it.
00:13:19.600 --> 00:13:21.919
And how do you gain the enterprise's trust?
00:13:22.080 --> 00:13:28.559
You know, you're now a series A startup, but previously you were a C stage startup and you're selling to massive organizations.
00:13:28.720 --> 00:13:30.480
So what did that take?
00:13:30.799 --> 00:13:32.559
It is challenging selling to enterprise.
00:13:32.720 --> 00:13:34.559
The contracting cycles are very long.
00:13:34.720 --> 00:13:43.200
We've had cases where some contracts were closed within a week, other cases where it's taken us over two years to redline a particular contract.
00:13:43.440 --> 00:13:49.360
And I think some of it again is since we've spent over decades in the space working with enterprises.
00:13:49.519 --> 00:13:54.320
So building upon kind of like trust that we've demonstrated in these areas in the field.
00:13:54.559 --> 00:14:06.480
And some of it is also from the beginning, we've really invested in a lot of the security and data governance and like a platform layer investments when some might argue, oh, you've done that before product market fit.
00:14:06.720 --> 00:14:18.720
So a lot of kind of like every startup, I guess, journey is unique, but in some cases, folks will think you have to follow the specific playbook of you put out an MVP, like that doesn't work anymore.
00:14:18.879 --> 00:14:23.360
Or what is an MVP is very different for us versus other companies.
00:14:23.600 --> 00:14:26.159
So for us, we had to be on multi-cloud.
00:14:26.240 --> 00:14:29.039
So like for some companies, they never even deploy more than one cloud.
00:14:29.120 --> 00:14:30.960
So we're deployed on all three clouds.
00:14:31.200 --> 00:14:39.840
We've had to chase a lot of the different compliances, whether the GDPRs, the HIPAA, and like we had to implement regional support, which for a lot of companies that is a big lift.
00:14:40.080 --> 00:14:43.120
But if you're an infrastructure company, that is table six.
00:14:43.279 --> 00:14:46.799
So I think some of these early investments have paid out.
00:14:46.879 --> 00:14:56.240
And as opposed to trying to build everything in like one microservice and trying to prove what a simple MVP is, I think people are that no longer holds water.
00:14:56.559 --> 00:14:59.759
And you mentioned the FDE model, something that you're leveraging.
00:15:00.080 --> 00:15:06.559
FDE seems to be the new AI engineer title in the sense of everyone's hiring FDEs right now.
00:15:06.879 --> 00:15:08.720
What is your definition of an FDE?
00:15:08.799 --> 00:15:12.480
And have there been any learnings of like what's worked or what hasn't worked?
00:15:12.799 --> 00:15:15.679
So we call them, like you said, applied AI.
00:15:15.840 --> 00:15:21.440
So we have various kinds of there's applied AI data science, applied AI engineers, and applied AI strategists.
00:15:21.600 --> 00:15:34.639
And the idea is these folks are engineers or come from strong backgrounds, either either across different sciences or other kind of like fields where they've demonstrated a strong track record.
00:15:34.879 --> 00:15:37.840
But these folks are basically at the edge of the problem.
00:15:38.000 --> 00:16:08.240
They're not necessarily building the engine that is behind Lemma, but they are building with Lemma and they they have the intimate understanding of the enterprises' APIs and data problems, and they can basically go from very raw customer requirements and draw them onto the platform in a way that still kind of like holds attention of making sure the customer is set up for success, but also in a way that optimizes for how our platform is built.
00:16:08.480 --> 00:16:20.960
So they understand basically how the data movement should go or push for which particular kind of like workflow or component or template, or they also understand which models to use when.
00:16:43.840 --> 00:16:53.679
But parts of the stack where understanding the messy data, messy customer requirements, or like operating on imperfect information, that is not a solved problem yet.
00:16:53.840 --> 00:16:56.960
But we'll see kind of like how that shakes out.
00:16:57.279 --> 00:17:02.559
How long are the engagements when you typically send like an FDEN to work with a customer?
00:17:02.879 --> 00:17:05.599
Again, it depends on the customer readiness.
00:17:05.839 --> 00:17:17.200
So if you're working with a customer and they are quote unquote AI or data ready, they have their data cleaned and their processes mapped out, that should be very quick.
00:17:17.359 --> 00:17:22.640
Our platform is self-service, so you can get a tenant set up and running in like a matter of minutes.
00:17:22.960 --> 00:17:48.960
But if you're working with cases where the landscape kind of like you're helping kind of like shape and organize how the data should be organized, or cases where the customer, maybe some of the existing workflows or legacy systems don't actually have APIs or don't have, or for sometimes for political reasons, like they're working with a number of different vendors and they don't want to give you access to some data, obviously, some of that is challenging.
00:17:49.039 --> 00:17:53.200
And like for that, there's different kinds of ways of building out these workflows.
00:17:53.440 --> 00:17:59.200
So in cases where everything's great, data's ready, APIs are there, it should be like self-service.
00:17:59.519 --> 00:18:19.200
But cases where you have to work with understanding if like that problem is actually the right problem to solve and there's a lot of iteration on the data, or for whatever reason, you are not getting access to all the data that you thought you were going to get access to, then it becomes a little bit more challenging and could take up some time.
00:18:19.599 --> 00:18:28.960
How have you learned what customers to say no to in the sense of you're working with pretty risk-averse buyers and financial services, public safety, healthcare?
00:18:29.039 --> 00:18:37.039
And I can't imagine everyone's a good fit for Lemma, but obviously you want to try to service these potential large ACVs.
00:18:37.359 --> 00:19:12.160
So yeah, a lot of the customers that we we're mostly prioritizing enterprise use cases, and these tend to have different kind of like a shape of a of a contract in cases where a lot of the problems can be solved with you know simple knowledge work or kind of like the latest and greatest tooling, like or where it doesn't make sense to deploy this kind of infrastructure, or it could be like an overkill kind of solution, and those cases where we would basically, yeah, like either direct the customer to like even if it's a competitor, be like this problem can actually be solved um this way.
00:19:12.480 --> 00:19:22.400
But cases where you actually need the different auditability and data governance and reliability and and the control, those are the ones that are best suited for our platform.
00:19:22.720 --> 00:19:26.160
And are they typically comparing you all to something they have internally?
00:19:26.319 --> 00:19:29.920
Then if you look ahead five, 10 years, what does agent orchestration look like?
00:19:30.319 --> 00:19:35.839
So I think it's it's a very exciting and interesting space.
00:19:35.920 --> 00:19:44.720
And I think we're seeing kind of like a lot of entrants, which usually is good market validation, the only person building a particular kind of a problem.
00:19:45.200 --> 00:19:59.440
But but I think what's very exciting for us is being able to cut across systems that are legacy and put some of these like very powerful building blocks in the hands of a lot of these users.
00:19:59.599 --> 00:20:15.519
And I think a lot of interesting things are happening now, cutting across the application and the infrastructure layer, and how you seamlessly bring that surface that up all the way to the apply to the end user experience is going to be very interesting.
00:20:15.680 --> 00:20:30.960
So, like things where there's certain things that are completely like you're dealing with like ingress and egress and VPNs and like peering and like a lot of these like networking constraints, but at the same time, your end user is might not be as familiar with these.
00:20:31.039 --> 00:20:44.319
So, how do you intentionally surface some of these nouns in a way that empowers that end builder without having them know and spend years basically like understanding distributed systems or like networking?
00:20:44.480 --> 00:20:55.920
And yeah, I think it's gonna be a lot of fun also combining kind of like seeing how some of the coding tools has disrupted kind of like the software development lifecycle.
00:20:56.160 --> 00:21:08.799
And how do we bring some of these tools across these different kinds of systems in a way that is still gives you the control and without completely like giving up autonomy?
00:21:09.039 --> 00:21:11.519
So that's been kind of like a very interesting theme for us.
00:21:11.759 --> 00:21:13.279
This idea of controlled autonomy.
00:21:13.440 --> 00:21:35.359
How do we have these workflows, these long-running self-haling workflows that still you still have control, you still see what is happening and you still maintain the kill switches and the guardrails and potentially the cost constraints across them, but still have them run and do work for you without basically destroying your system.
00:21:35.680 --> 00:21:42.559
Have you seen anything gone wrong yet when you've been deploying using these autonomous systems, or is it too early?
00:21:42.880 --> 00:21:53.279
Basically, the way we've built our infrastructure, our platform, Lemma is making sure that we continue to maintain these controls around execution and plan generation.
00:21:53.599 --> 00:21:58.240
Because, like oftentimes, there are these checks and balances with the kinds of workflows that we build.
00:21:58.480 --> 00:22:08.079
There's cases where you Want your agents to run completely autonomously, or if you've defined kind of like either a cost constraint for them or like certain system boundaries, you could do that.
00:22:08.400 --> 00:22:16.160
But in many cases, we take a very strong stance around separating the execution from the generation.
00:22:16.559 --> 00:22:19.680
And I guess like a little bit of implementation detail.
00:22:19.759 --> 00:22:40.880
So often, so even when so our platform also supports like importing MCP servers, for example, but we take a very glass box approach where you know exactly which tools could be invoked or will be invoked, and you can select and remove like certain tools versus kind of like pulling in an entire server and giving it full control with natural language.
00:22:41.039 --> 00:22:49.039
You could do that, but oftentimes we will surface what is actually happening because we want to push our users to know what is happening in their system.
00:22:49.279 --> 00:22:49.839
That makes sense.
00:22:50.079 --> 00:22:55.759
I would love to switch gears slightly and chat about hiring and how you've thought about building a team.
00:22:55.839 --> 00:22:59.200
The AI talent war is real and it's extremely competitive.
00:22:59.279 --> 00:23:05.680
And you guys have scaled from single to double-digit folks in a very short amount of time.
00:23:05.839 --> 00:23:10.799
And so I'm curious how you've thought about hiring, specifically building in New York.
00:23:11.119 --> 00:23:14.640
So we're very much New York-based company.
00:23:14.720 --> 00:23:17.279
We've actually made a lot of folks relocate.
00:23:17.359 --> 00:23:19.839
It's very bullish on the New York market and talent.
00:23:20.000 --> 00:23:24.240
But obviously, as we grow, some of these strong beliefs might change.
00:23:24.319 --> 00:23:28.079
And we'll think about kind of like what growing across other regions look like.
00:23:28.319 --> 00:23:35.599
But for us, from the get-go, we try to focus on folks who are very strong at fundamentals, distributed systems, fundamentals.
00:23:35.759 --> 00:23:46.240
There's often cases where we're happy to teach people quote unquote the AI or a lot of like the new, the latest and greatest tooling, as long as they have a deep bench in a particular area.
00:23:46.400 --> 00:23:47.440
Obviously, with different roles.
00:23:47.519 --> 00:23:52.640
If you're a data scientist, there's specific things for, and if you're a back-end or infrastructure engineer, there's other things.
00:23:52.799 --> 00:23:56.559
But generally look for folks who take pride in strong ownership.
00:23:56.720 --> 00:24:01.119
They're very hungry, very excited about the space, and have very strong fundamentals.
00:24:01.279 --> 00:24:15.279
Our process isn't very different, but there's some cases where we've borrowed from some of the best like tech companies, and some some cases where we borrowed from very unique, forward-deployed kind of like types of thinking and how we evaluate people.
00:24:15.440 --> 00:24:21.279
So folks need to be able to build things for planet scale, but still be able to hold that tension.
00:24:21.359 --> 00:24:29.039
If you need to deliver something within a week, you understand what assumptions you're making and you know how to unwind them and turn it into a real product.
00:24:29.200 --> 00:24:36.720
So folks who are comfortable delivering under very different kinds of circumstances, but they know the depth of what that looks like.
00:24:36.880 --> 00:24:44.640
And a lot of tech companies now are also fundamentally changing their interview process to account for how software is changing.
00:24:44.799 --> 00:25:02.079
But again, like a lot of that is you're still looking for folks who want to dig into the details, want to take systems apart, are very strong communicators, and are not scared of owning end-to-end outcomes, even if it touches systems that maybe that is not kind of like their main area of expertise.
00:25:02.400 --> 00:25:08.799
This profile seems popular right now amongst a lot of your competitors and some of the big tech companies.
00:25:08.880 --> 00:25:11.200
So how do you think about winning candidates?
00:25:11.519 --> 00:25:14.799
It is, yeah, it is kind of like a fun talent war.
00:25:15.359 --> 00:25:25.039
But a lot of cases where we've won is we have access to a lot of problems that oftentimes it takes an enterprise years to get access to.
00:25:25.200 --> 00:25:33.920
Whether it's working across the US government or some of the largest companies in the world, oftentimes startups will not have access to these problems.
00:25:34.000 --> 00:25:48.319
And I think many cases where we've seen kind of like we've won candidates over others, folks have been motivated by these hard problems that cut across systems and working with like folks who have a very strong track record.
00:25:48.559 --> 00:26:04.559
So, like on the team, we have folks who worked at some of the best and some of the largest companies in the world and built systems like App Engine or Twilio's workflow studio engine, and as well as some of the other folks we worked with at Palentier.
00:26:04.799 --> 00:26:10.240
How have you thought about stepping into a new managerial like leadership role?
00:26:10.400 --> 00:26:14.079
How have you learned to lead teams and to rally folks around you?
00:26:14.559 --> 00:26:18.559
And maybe if you've made any mistakes or have any stories to share?
00:26:19.200 --> 00:26:26.400
So both Angela and I from Palantir days have all have had more people leads in addition to being ICs.
00:26:26.559 --> 00:26:35.279
And I think that is a strong kind of like tenet that we hold, not we we always we don't believe in just having middle management.
00:26:35.440 --> 00:26:40.720
Everyone in the company is a builder, so it doesn't matter that your level of seniority or tenure.
00:26:40.799 --> 00:27:00.559
Um yes, you might be people lead and in charge of helping growing others, but at the heart of it, you're still a builder, you're still tinkering with systems, whether it's if you're still writing code or prototyping or writing RFCs, we push for folks who continue to have that muscle as opposed to just managing folks.
00:27:00.640 --> 00:27:11.680
And I think that's kind of like been the model in which we lead people because people often want to see that you are leading by example, you can step in and they can trust you as a leader.
00:27:11.920 --> 00:27:13.119
And it's and it's exciting now.
00:27:13.200 --> 00:27:28.079
We're seeing a lot of people return back to writing and building code with basically a lot of the tooling that's available right now, where some problems may have been now too abstracted away, or like we're seeing like a lot of leadership return to basically building.
00:27:28.400 --> 00:27:31.920
What is your role distribution of a building versus a managing at this point?
00:27:32.000 --> 00:27:34.640
And the what point in a company's growth does it tend to shift?
00:27:34.880 --> 00:27:50.000
I guess right now, since we're a very flat organization, and would say the majority of the company reports to me and Angela, lopsided, but it'll be kind of like interesting to see how we scale and grow the team that we've built with us.
00:27:50.160 --> 00:27:54.160
I would say, yeah, we try to still pretty much active.
00:27:54.240 --> 00:28:00.559
So we had a hackathon last Friday, and basically a lot of us, yeah, participated, which is kind of like exciting.
00:28:00.720 --> 00:28:07.680
And I think being intentional around the time split, I think will be important as we grow.
00:28:07.839 --> 00:28:11.920
And probably at some point we will not have everyone reporting to us.
00:28:12.160 --> 00:28:12.319
Yeah.
00:28:12.480 --> 00:28:13.759
But no, that makes a ton of sense.
00:28:14.000 --> 00:28:16.720
So the agentic wave, as you know, is moving incredibly fast.
00:28:16.880 --> 00:28:20.480
I'm curious, where do you think the enterprise infrastructure layer settles?
00:28:20.559 --> 00:28:24.400
Do you think it's winner take all, or do you think it's a bit more fragmented than that?
00:28:24.799 --> 00:28:29.759
I guess there will continue to be room for a lot of different fragmentation.
00:28:29.920 --> 00:28:38.559
Obviously, there's a lot of folks who have made investments in their different hyperscalers and the tooling within that because the economics kind of like makes sense.
00:28:38.720 --> 00:28:44.240
But there are very much a lot of systems now that are being rebuilt from the ground up.
00:28:44.480 --> 00:29:02.480
For us, the the nice part about our infrastructure is oftentimes, like with enterprises, you don't have to blast your stack in order to use or start building safely with AI, which has been kind of like the main nice entry point for us because telling an enterprise you have to redo your whole stack is sometimes like a non-starter.
00:29:02.720 --> 00:29:09.920
But there's gonna be like an interesting wave right now where there's a lot of folks who think with the coding tools that they can build everything.
00:29:10.079 --> 00:29:17.440
So there's a little bit of an overcorrection of a lot of folks building in-house, and then there's gonna be like market correction.
00:29:17.519 --> 00:29:19.519
It's like almost like the reinvention of SAS.
00:29:19.839 --> 00:29:21.839
There are some things people realize actually, no.
00:29:22.000 --> 00:29:27.599
I mean, because writing code wasn't that really the hard problem, but like the last 10% is the hardest problem.
00:29:27.759 --> 00:29:32.400
Putting it in production and knowing that it's gonna scale or it's not gonna fail at 3 a.m.
00:29:32.640 --> 00:29:35.839
or under these certain constraints it's gonna recover.
00:29:36.000 --> 00:29:39.200
That is always kind of like has been the annoying problem.
00:29:39.359 --> 00:29:45.039
But I think right now there's like a lot of hype and buzz where everyone thinks they can build everything, which is which is great and exciting.
00:29:45.119 --> 00:29:54.240
But there's gonna be kind of like I think Q three or four big kind of like collapses or big large security kind of like problems.
00:29:54.480 --> 00:29:55.279
I'm already seeing it.
00:29:55.359 --> 00:29:55.519
Yeah.
00:29:55.680 --> 00:29:57.839
And then the market will naturally correct itself.
00:29:58.160 --> 00:30:04.319
And I think like, yeah, companies that have demonstrated that they've earned the right to be in this space will continue to be in this space.
00:30:04.400 --> 00:30:06.480
And then there's gonna be a lot of companies like will shut down.
00:30:06.720 --> 00:30:09.200
What are the like roles that you're hiring for right now?
00:30:09.440 --> 00:30:10.960
Any ending thoughts that you have?
00:30:11.359 --> 00:30:12.319
We're very excited.
00:30:12.480 --> 00:30:20.319
I think we've put up now a couple new exciting roles across the business operations side of the house and also the federal side of the house.
00:30:20.559 --> 00:30:29.519
We've done the hard work of going from zero to one across federal, and now we're looking for folks who are experts and can scale the machine with us.
00:30:29.680 --> 00:30:34.000
And of course, always looking for strong engineers and across Apply.
00:30:40.319 --> 00:30:40.880
Awesome.
00:30:41.119 --> 00:30:42.880
Well, thank you so much for coming on, Maya.
00:30:43.039 --> 00:30:43.279
Awesome.
00:30:43.359 --> 00:30:43.839
Thank you for having me.
00:30:44.000 --> 00:30:44.720
This was great.
00:00:00.160 --> 00:00:10.240
A lot of the agents and workflows that we build are mostly focused around mission critical multi-step processes that often involve different kinds of personas.
00:00:10.720 --> 00:00:16.879
So they're not agents for just end-to-end knowledge work that usually starts and ends with a person.
00:00:17.280 --> 00:00:19.280
They're usually multi-step processes.
00:00:19.359 --> 00:00:29.679
So think of things like invoice processing, end-to-end invoice processing and correction, or diligence reporting, or different kinds of multi-step monitoring systems.
00:00:30.000 --> 00:00:33.200
Most podcasts talk to founders after the story is already written.
00:00:33.359 --> 00:00:36.960
When the latest trade is announced, the product has shipped and the narrative is clean.
00:00:37.280 --> 00:00:40.719
We wanted to find out why they decided to take the founder leap in the first place.
00:00:40.880 --> 00:00:44.719
What idea captured their imagination and how they handle the pressure to build?
00:00:44.880 --> 00:00:45.840
Welcome to First Commit.
00:00:46.079 --> 00:00:46.960
I'm Laura Hamilton.
00:00:47.280 --> 00:00:50.159
I'm Elie Lone and we're investors at Federal Capital.
00:00:50.320 --> 00:00:53.520
We spend a lot of time with technical founders who are on the cutting edge.
00:00:53.679 --> 00:00:57.520
If you're thinking about what it's like to start a company in the AI era, this one's for you.
00:00:57.759 --> 00:00:58.799
This is First Commit.
00:00:59.039 --> 00:01:00.240
Let's get into it.
00:01:01.359 --> 00:01:03.920
Today we are chatting with Maya from Thread AI.
00:01:04.079 --> 00:01:07.920
Maya is the co-founder and CTO working on AI native orchestration.
00:01:08.079 --> 00:01:08.799
Welcome, Maya.
00:01:09.040 --> 00:01:09.840
It's great to be here.
00:01:10.079 --> 00:01:11.120
It's great to have you.
00:01:11.359 --> 00:01:17.120
So you came up through Goldman Sachs and built the digital subscriptions platform at the New York Times before landing at Palantir.
00:01:17.200 --> 00:01:23.519
It would be great if you could touch on the thread connecting all those experiences and when you knew that you wanted to branch off on your own.
00:01:23.920 --> 00:01:32.239
Yeah, so I've spent, I want to say, the majority of my career working in across various regulated spaces and enterprises.
00:01:32.400 --> 00:01:42.000
So yeah, when I started my career at Goldman Sachs, I was primarily an infrastructure backend engineer, building software for various business divisions and prime brokerage and futures trading.
00:01:42.079 --> 00:01:49.519
So there was always this emphasis on security and data governance and understanding basically how to build software at scale.
00:01:49.760 --> 00:01:51.120
And that's been the theme.
00:01:51.280 --> 00:01:57.840
So even when I went to go work at the New York Times, I spent a good chunk of my career building out their payment systems.
00:01:57.920 --> 00:02:06.640
And so working directly with auditors and making sure that the infrastructure that we built is PCI compliant among other types of compliance.
00:02:06.799 --> 00:02:17.120
And similarly, the work that we've done at Palantir has been working with not just large government agencies like the defense, but also working with other large enterprises.
00:02:17.280 --> 00:02:23.120
And that's been the theme, whether we're building AI native software or other kinds of software.
00:02:23.280 --> 00:02:26.319
I spent a lot of my career working in these regulated spaces.
00:02:26.479 --> 00:02:45.840
So understanding their needs, and that has really helped shape the experience of how we think about building software at ThreadAI, understanding enterprises from basic principles and building software that fits their needs, as opposed to building a proof of concept and then trying to retrofit enterprise features into it.
00:02:46.159 --> 00:02:46.800
Yeah, that's great.
00:02:46.879 --> 00:02:51.680
We'll definitely get into how you're focusing on AI orchestration and what that means at Thread.
00:02:51.840 --> 00:02:55.280
But before that, I would love to dive deeper into your work at Palantir.
00:02:55.439 --> 00:03:01.680
So as you mentioned, you were building infrastructure that ended up in the hands of the DoD, but didn't get the clearance to see your work deployed.
00:03:01.759 --> 00:03:08.400
I would love to hear more about that story and kind of what that did psychologically to maybe fuel the fire.
00:03:08.719 --> 00:03:10.560
It was definitely a very interesting experience.
00:03:10.639 --> 00:03:14.400
So when I joined Palantir, I was not yet, like you mentioned, a US citizen.
00:03:14.639 --> 00:03:21.840
There were many cases where I had to build a lot of software, and I oftentimes would not see how it would get deployed in the field.
00:03:22.000 --> 00:03:28.080
And I think the main thing that has enforced is obviously working in a team with high trust.
00:03:28.240 --> 00:03:31.439
So I spent a lot of time working with my now co-founder, Angela.
00:03:31.520 --> 00:03:40.159
At the time, she had the clearance and access to the problems at the edge, and it really helped forge this strong work relationship.
00:03:40.319 --> 00:04:00.159
But also the main thread here is when you're building software, especially infrastructure, there's certain kinds of reliability guarantees and feature sets that we have to make sure exist so that you can have the peace of mind where knowing regardless of where your software is deployed, it is functioning according to whatever invariance that you've set.
00:04:00.319 --> 00:04:05.759
So there is a certain quality and certain bar that you have to make sure that each feature holds.
00:04:05.840 --> 00:04:08.080
And it's almost like building like a database.
00:04:08.319 --> 00:04:33.680
You can't simply assume that people are going to retry certain things or people are going to assume certain DevX or UX because you have to make sure that the software, however way it is used, it is always acting deterministically, or it is always surfacing the kinds of metrics and enforcing the certain feedback loops where it is behaving the same way whether it is deployed in low side or deployed on the moon or deployed wherever it is deployed.
00:04:33.920 --> 00:04:34.079
Okay.
00:04:34.240 --> 00:04:42.639
So then when you were at Palantir working with Angela, how did you know that one, she was the right person to work with, and two, that it was time to leave?
00:04:42.959 --> 00:04:46.000
We spent a lot of time working together on a lot of different projects.
00:04:46.160 --> 00:04:47.680
So she's also very technical.
00:04:47.839 --> 00:04:49.839
Her background is also engineering.
00:04:50.000 --> 00:04:55.519
And the interesting part is a lot of I think our skill sets is a nice Venn diagram.
00:04:55.680 --> 00:05:00.240
Whereas my background has been mostly spent in distributed systems and infrastructure.
00:05:00.399 --> 00:05:04.879
Her background has been mostly spent in working with data and intelligence systems.
00:05:05.040 --> 00:05:22.480
So that kind of like gave us a nice complete skill set of the things that you need to be able to build the kinds of software that you want to build across working closely with data and understanding data and working across infrastructure and deploying that in various kinds of modalities.
00:05:22.639 --> 00:05:25.519
And I think working at Palantir, we've learned a lot.
00:05:25.759 --> 00:05:33.199
You get access to crazy problems that maybe other software companies would not put engineers at the front line of.
00:05:33.360 --> 00:05:42.879
Oftentimes, a lot of software companies have many layers of abstractions away where there are the solutions architects and the different operational layers and the different kinds of testing.
00:05:42.959 --> 00:05:47.439
Whereas Talentier, they take bets on very strong autonomous software engineers.
00:05:47.600 --> 00:05:53.040
And oftentimes you'll find yourself meeting people that normally you wouldn't at any other tech company.
00:05:53.199 --> 00:05:57.040
And to your question around when did we think it was time to leave?
00:05:57.199 --> 00:05:59.839
I think that was around spring of 2023.
00:06:00.160 --> 00:06:02.160
And the market was very exciting.
00:06:02.240 --> 00:06:07.199
There was a lot of exciting things happening across different kinds of ML and language models.
00:06:07.360 --> 00:06:12.560
And I think we had a lot of conviction, knowing that we've known how to work together.
00:06:12.800 --> 00:06:17.759
For us, that was almost more important than sometimes like the specific idea.
00:06:17.839 --> 00:06:21.680
Because like we knew that whatever it is that we built, we know how to make it work.
00:06:21.839 --> 00:06:24.560
We spent a lot of time building horizontal infrastructure.
00:06:24.800 --> 00:06:31.519
And I think being excited about working together was almost, I would say, like more important than what idea we had at the time.
00:06:31.759 --> 00:06:39.920
Was there anything psychologically or EQ test that you ran just to ensure the partnership would be what you had in mind?
00:06:40.399 --> 00:06:45.519
I think I would say working closely together for over four years kind of like gave that.
00:06:45.759 --> 00:06:57.040
It's very challenging to take these large bets with someone that you've just met, mostly because you will be put in very difficult situations and oftentimes situations that will test your character.
00:06:57.199 --> 00:07:13.680
So knowing how you work very intimately with someone and making sure that your communication skills line up, whether it is how you how you surface disagreement or how you resolve conflicts or how knowing which problems and which hills to die on.
00:07:13.759 --> 00:07:21.199
And uh, and as long as I guess like uh co-founders know how to work that out, I think that is the most important thing.
00:07:21.439 --> 00:07:31.439
But I think, yeah, a lot of it uh came, I guess like for us, we were lucky because we were tried and tested already in previous kind of like lives, and that gave us kind of like the data points.
00:07:31.600 --> 00:07:49.839
But again, that's not to say that starting a company isn't a completely different beast, but at least you'll have kind of like a lot of the data points already if you've worked with someone that closely and within that capacity, which is different also from in some cases folks will think that they if they start a company with their friends, they know their friends and nothing really that's a very For sure.
00:07:49.920 --> 00:07:58.319
And it I mean it's very daunting to leave a safe job that you're enjoying and you're still learning a ton, and to start a company with someone but you don't know what you're starting yet.
00:07:58.560 --> 00:08:06.800
When you're thinking about brainstorming, how did you seek validation about early proof points that thread would be what it is today?
00:08:06.959 --> 00:08:09.120
Or maybe you started with a different idea.
00:08:09.519 --> 00:08:13.839
We were fortunate in that I would say we haven't pivoted from when we started.
00:08:14.000 --> 00:08:20.720
So a lot of the time that we spent at Pound Tier was mostly building ML ops, to building model training, model inference, model evaluation systems.
00:08:20.879 --> 00:08:30.240
And we knew that we did not want or could not even build whatever it is that we build at Pound Tier for various different reasons, but also that was not the space that we wanted to be in.
00:08:30.399 --> 00:08:33.519
We were very interested in everything that happened downstream of that.
00:08:33.679 --> 00:08:40.559
So everything downstream of ML ops because we knew that models will continue to be more ubiquitous, more available.
00:08:40.720 --> 00:08:46.320
There will be a lot of interesting things, the model will continue to improve, there will always be like model drops every week.
00:08:46.639 --> 00:08:55.120
But the hypothesis was that enterprises will still have very unique challenges operationalizing these models for different kinds of reasons.
00:08:55.200 --> 00:08:58.080
And the models cut across infrastructure and application layer.
00:08:58.240 --> 00:09:06.559
They they now are mixing and matching multimodality, which, like in previous worlds, that was that was almost like completely separate infrastructures.
00:09:06.799 --> 00:09:10.799
And we've really admired what some of the orchestration companies have done.
00:09:10.960 --> 00:09:18.240
So around 2023, we knew that companies like Temporal and Conductor have solved for a lot of the durability and core orchestration problems.
00:09:18.320 --> 00:09:24.799
But at the time, we noticed that they haven't solved for the non-determinism that comes with AI models.
00:09:25.039 --> 00:09:27.679
So we thought there's a lot of market for in that space.
00:09:27.919 --> 00:09:34.080
And we were also really inspired by that tool former paper that came out of Meta, I think early 2023.
00:09:34.240 --> 00:09:38.559
And that but that paper was mostly focused around language models and giving them access to tools.
00:09:38.720 --> 00:09:50.720
We knew that enterprises were not going to train specific on specific APIs, but we thought a lot of the ideas behind that paper were very interesting, almost interesting enough for someone to quit their job.
00:09:50.879 --> 00:09:59.360
And I think that paper was almost like the inception of a lot of what we see right now: things like function calling, tool calling, MCP and agent.
00:09:59.519 --> 00:10:03.519
And that's been kind of like that space that's now getting a lot of traction.
00:10:03.679 --> 00:10:08.240
But we knew basically to be able to do that for a large enterprise.
00:10:08.399 --> 00:10:17.360
And not understanding like the enterprise ecosystem, which oftentimes has a lot of legacy systems, has a combination of vertical software, has different kinds of like data problems.
00:10:17.519 --> 00:10:24.080
Being able to build these kinds of agents that meet enterprise guarantees is a very hard problem.
00:10:24.399 --> 00:10:28.240
But and usually hard problems have like decent markets.
00:10:28.480 --> 00:10:31.440
And I would love to touch on what types of agents you're building for the enterprise.
00:10:31.519 --> 00:10:41.279
Because I can imagine there's some use cases where you're seeing parallelism between one enterprise and another and more software, but I can imagine a lot of use cases could be more services heavy.
00:10:41.360 --> 00:10:44.879
So I'm curious how you balance the services versus software approach at thread.
00:10:45.200 --> 00:10:52.559
We've learned a lot and again, how what works well with the forward deployed, what doesn't work well with the forward deployed model.
00:10:52.799 --> 00:10:58.080
And for us, when we started, it was always we knew we always wanted to build a product and a platform.
00:10:58.320 --> 00:11:02.639
But obviously, there is always kind of like some customization that has to happen.
00:11:02.799 --> 00:11:11.279
But oftentimes, enterprises are also, if you teach them and they're they are willing to work on these specific customizations.
00:11:11.360 --> 00:11:19.360
So you can always kind of like sometimes push back on some of these specific bespoke customizations and have the customer own a lot of that.
00:11:19.600 --> 00:11:29.759
A lot of the agents and workflows that we build are mostly focused around mission critical multi-step processes that often involve different kinds of personas.
00:11:30.159 --> 00:11:36.399
So they're not agents for just end-to-end knowledge work that usually starts and ends with a person.
00:11:36.720 --> 00:11:38.799
They're usually multi-step processes.
00:11:38.879 --> 00:11:53.120
So think of things like invoice processing, end-to-end invoice processing and correction, or diligence reporting, or different kinds of multi-step monitoring systems, or triaging workflows that involve mechanics in the field.
00:11:53.360 --> 00:12:08.879
And oftentimes you these workflows have data capture, so things from physical systems, and they often will require you to run large workloads asynchronously, and then they'll sometimes require an investment in a human of the loop.
00:12:09.039 --> 00:12:12.240
So usually a person who has domain expertise.
00:12:12.320 --> 00:12:15.840
So they're not necessarily the person, the builder, the person who created the workflow.
00:12:16.000 --> 00:12:21.679
They're not necessarily like that kind of persona, but they oftentimes are the domain experts.
00:12:21.840 --> 00:12:31.919
So let's say you're it is an insurance claim processing workflow, they would be the ones who have go or no go and around the outputs of the models.
00:12:32.080 --> 00:12:40.639
So they basically would stop when the workflow stopped and their feedback is solicited, they would know whether to correct it or deposit or to reroute it.
00:12:40.799 --> 00:12:50.159
And then basically a lot of these workflows oftentimes will push out data to the customers' things, whether it's their own data lake or like some kind of notification system.
00:12:50.639 --> 00:12:57.120
And our infrastructure makes it very easy to swap in and out models to create.
00:12:57.279 --> 00:13:03.600
We've invested a lot in the separation of data and compute, so creating a very interesting context layer.
00:13:03.840 --> 00:13:12.240
So we handle a lot of the data movement that comes with that data entry and eviction and help enterprises basically connect that to their systems.
00:13:12.480 --> 00:13:18.799
So oftentimes these workflows are long-running, multi-step, and involve different kinds of personas interacting with them.
00:13:19.120 --> 00:13:19.519
Got it.
00:13:19.600 --> 00:13:21.919
And how do you gain the enterprise's trust?
00:13:22.080 --> 00:13:28.559
You know, you're now a series A startup, but previously you were a C stage startup and you're selling to massive organizations.
00:13:28.720 --> 00:13:30.480
So what did that take?
00:13:30.799 --> 00:13:32.559
It is challenging selling to enterprise.
00:13:32.720 --> 00:13:34.559
The contracting cycles are very long.
00:13:34.720 --> 00:13:43.200
We've had cases where some contracts were closed within a week, other cases where it's taken us over two years to redline a particular contract.
00:13:43.440 --> 00:13:49.360
And I think some of it again is since we've spent over decades in the space working with enterprises.
00:13:49.519 --> 00:13:54.320
So building upon kind of like trust that we've demonstrated in these areas in the field.
00:13:54.559 --> 00:14:06.480
And some of it is also from the beginning, we've really invested in a lot of the security and data governance and like a platform layer investments when some might argue, oh, you've done that before product market fit.
00:14:06.720 --> 00:14:18.720
So a lot of kind of like every startup, I guess, journey is unique, but in some cases, folks will think you have to follow the specific playbook of you put out an MVP, like that doesn't work anymore.
00:14:18.879 --> 00:14:23.360
Or what is an MVP is very different for us versus other companies.
00:14:23.600 --> 00:14:26.159
So for us, we had to be on multi-cloud.
00:14:26.240 --> 00:14:29.039
So like for some companies, they never even deploy more than one cloud.
00:14:29.120 --> 00:14:30.960
So we're deployed on all three clouds.
00:14:31.200 --> 00:14:39.840
We've had to chase a lot of the different compliances, whether the GDPRs, the HIPAA, and like we had to implement regional support, which for a lot of companies that is a big lift.
00:14:40.080 --> 00:14:43.120
But if you're an infrastructure company, that is table six.
00:14:43.279 --> 00:14:46.799
So I think some of these early investments have paid out.
00:14:46.879 --> 00:14:56.240
And as opposed to trying to build everything in like one microservice and trying to prove what a simple MVP is, I think people are that no longer holds water.
00:14:56.559 --> 00:14:59.759
And you mentioned the FDE model, something that you're leveraging.
00:15:00.080 --> 00:15:06.559
FDE seems to be the new AI engineer title in the sense of everyone's hiring FDEs right now.
00:15:06.879 --> 00:15:08.720
What is your definition of an FDE?
00:15:08.799 --> 00:15:12.480
And have there been any learnings of like what's worked or what hasn't worked?
00:15:12.799 --> 00:15:15.679
So we call them, like you said, applied AI.
00:15:15.840 --> 00:15:21.440
So we have various kinds of there's applied AI data science, applied AI engineers, and applied AI strategists.
00:15:21.600 --> 00:15:34.639
And the idea is these folks are engineers or come from strong backgrounds, either either across different sciences or other kind of like fields where they've demonstrated a strong track record.
00:15:34.879 --> 00:15:37.840
But these folks are basically at the edge of the problem.
00:15:38.000 --> 00:16:08.240
They're not necessarily building the engine that is behind Lemma, but they are building with Lemma and they they have the intimate understanding of the enterprises' APIs and data problems, and they can basically go from very raw customer requirements and draw them onto the platform in a way that still kind of like holds attention of making sure the customer is set up for success, but also in a way that optimizes for how our platform is built.
00:16:08.480 --> 00:16:20.960
So they understand basically how the data movement should go or push for which particular kind of like workflow or component or template, or they also understand which models to use when.
00:16:43.840 --> 00:16:53.679
But parts of the stack where understanding the messy data, messy customer requirements, or like operating on imperfect information, that is not a solved problem yet.
00:16:53.840 --> 00:16:56.960
But we'll see kind of like how that shakes out.
00:16:57.279 --> 00:17:02.559
How long are the engagements when you typically send like an FDEN to work with a customer?
00:17:02.879 --> 00:17:05.599
Again, it depends on the customer readiness.
00:17:05.839 --> 00:17:17.200
So if you're working with a customer and they are quote unquote AI or data ready, they have their data cleaned and their processes mapped out, that should be very quick.
00:17:17.359 --> 00:17:22.640
Our platform is self-service, so you can get a tenant set up and running in like a matter of minutes.
00:17:22.960 --> 00:17:48.960
But if you're working with cases where the landscape kind of like you're helping kind of like shape and organize how the data should be organized, or cases where the customer, maybe some of the existing workflows or legacy systems don't actually have APIs or don't have, or for sometimes for political reasons, like they're working with a number of different vendors and they don't want to give you access to some data, obviously, some of that is challenging.
00:17:49.039 --> 00:17:53.200
And like for that, there's different kinds of ways of building out these workflows.
00:17:53.440 --> 00:17:59.200
So in cases where everything's great, data's ready, APIs are there, it should be like self-service.
00:17:59.519 --> 00:18:19.200
But cases where you have to work with understanding if like that problem is actually the right problem to solve and there's a lot of iteration on the data, or for whatever reason, you are not getting access to all the data that you thought you were going to get access to, then it becomes a little bit more challenging and could take up some time.
00:18:19.599 --> 00:18:28.960
How have you learned what customers to say no to in the sense of you're working with pretty risk-averse buyers and financial services, public safety, healthcare?
00:18:29.039 --> 00:18:37.039
And I can't imagine everyone's a good fit for Lemma, but obviously you want to try to service these potential large ACVs.
00:18:37.359 --> 00:19:12.160
So yeah, a lot of the customers that we we're mostly prioritizing enterprise use cases, and these tend to have different kind of like a shape of a of a contract in cases where a lot of the problems can be solved with you know simple knowledge work or kind of like the latest and greatest tooling, like or where it doesn't make sense to deploy this kind of infrastructure, or it could be like an overkill kind of solution, and those cases where we would basically, yeah, like either direct the customer to like even if it's a competitor, be like this problem can actually be solved um this way.
00:19:12.480 --> 00:19:22.400
But cases where you actually need the different auditability and data governance and reliability and and the control, those are the ones that are best suited for our platform.
00:19:22.720 --> 00:19:26.160
And are they typically comparing you all to something they have internally?
00:19:26.319 --> 00:19:29.920
Then if you look ahead five, 10 years, what does agent orchestration look like?
00:19:30.319 --> 00:19:35.839
So I think it's it's a very exciting and interesting space.
00:19:35.920 --> 00:19:44.720
And I think we're seeing kind of like a lot of entrants, which usually is good market validation, the only person building a particular kind of a problem.
00:19:45.200 --> 00:19:59.440
But but I think what's very exciting for us is being able to cut across systems that are legacy and put some of these like very powerful building blocks in the hands of a lot of these users.
00:19:59.599 --> 00:20:15.519
And I think a lot of interesting things are happening now, cutting across the application and the infrastructure layer, and how you seamlessly bring that surface that up all the way to the apply to the end user experience is going to be very interesting.
00:20:15.680 --> 00:20:30.960
So, like things where there's certain things that are completely like you're dealing with like ingress and egress and VPNs and like peering and like a lot of these like networking constraints, but at the same time, your end user is might not be as familiar with these.
00:20:31.039 --> 00:20:44.319
So, how do you intentionally surface some of these nouns in a way that empowers that end builder without having them know and spend years basically like understanding distributed systems or like networking?
00:20:44.480 --> 00:20:55.920
And yeah, I think it's gonna be a lot of fun also combining kind of like seeing how some of the coding tools has disrupted kind of like the software development lifecycle.
00:20:56.160 --> 00:21:08.799
And how do we bring some of these tools across these different kinds of systems in a way that is still gives you the control and without completely like giving up autonomy?
00:21:09.039 --> 00:21:11.519
So that's been kind of like a very interesting theme for us.
00:21:11.759 --> 00:21:13.279
This idea of controlled autonomy.
00:21:13.440 --> 00:21:35.359
How do we have these workflows, these long-running self-haling workflows that still you still have control, you still see what is happening and you still maintain the kill switches and the guardrails and potentially the cost constraints across them, but still have them run and do work for you without basically destroying your system.
00:21:35.680 --> 00:21:42.559
Have you seen anything gone wrong yet when you've been deploying using these autonomous systems, or is it too early?
00:21:42.880 --> 00:21:53.279
Basically, the way we've built our infrastructure, our platform, Lemma is making sure that we continue to maintain these controls around execution and plan generation.
00:21:53.599 --> 00:21:58.240
Because, like oftentimes, there are these checks and balances with the kinds of workflows that we build.
00:21:58.480 --> 00:22:08.079
There's cases where you Want your agents to run completely autonomously, or if you've defined kind of like either a cost constraint for them or like certain system boundaries, you could do that.
00:22:08.400 --> 00:22:16.160
But in many cases, we take a very strong stance around separating the execution from the generation.
00:22:16.559 --> 00:22:19.680
And I guess like a little bit of implementation detail.
00:22:19.759 --> 00:22:40.880
So often, so even when so our platform also supports like importing MCP servers, for example, but we take a very glass box approach where you know exactly which tools could be invoked or will be invoked, and you can select and remove like certain tools versus kind of like pulling in an entire server and giving it full control with natural language.
00:22:41.039 --> 00:22:49.039
You could do that, but oftentimes we will surface what is actually happening because we want to push our users to know what is happening in their system.
00:22:49.279 --> 00:22:49.839
That makes sense.
00:22:50.079 --> 00:22:55.759
I would love to switch gears slightly and chat about hiring and how you've thought about building a team.
00:22:55.839 --> 00:22:59.200
The AI talent war is real and it's extremely competitive.
00:22:59.279 --> 00:23:05.680
And you guys have scaled from single to double-digit folks in a very short amount of time.
00:23:05.839 --> 00:23:10.799
And so I'm curious how you've thought about hiring, specifically building in New York.
00:23:11.119 --> 00:23:14.640
So we're very much New York-based company.
00:23:14.720 --> 00:23:17.279
We've actually made a lot of folks relocate.
00:23:17.359 --> 00:23:19.839
It's very bullish on the New York market and talent.
00:23:20.000 --> 00:23:24.240
But obviously, as we grow, some of these strong beliefs might change.
00:23:24.319 --> 00:23:28.079
And we'll think about kind of like what growing across other regions look like.
00:23:28.319 --> 00:23:35.599
But for us, from the get-go, we try to focus on folks who are very strong at fundamentals, distributed systems, fundamentals.
00:23:35.759 --> 00:23:46.240
There's often cases where we're happy to teach people quote unquote the AI or a lot of like the new, the latest and greatest tooling, as long as they have a deep bench in a particular area.
00:23:46.400 --> 00:23:47.440
Obviously, with different roles.
00:23:47.519 --> 00:23:52.640
If you're a data scientist, there's specific things for, and if you're a back-end or infrastructure engineer, there's other things.
00:23:52.799 --> 00:23:56.559
But generally look for folks who take pride in strong ownership.
00:23:56.720 --> 00:24:01.119
They're very hungry, very excited about the space, and have very strong fundamentals.
00:24:01.279 --> 00:24:15.279
Our process isn't very different, but there's some cases where we've borrowed from some of the best like tech companies, and some some cases where we borrowed from very unique, forward-deployed kind of like types of thinking and how we evaluate people.
00:24:15.440 --> 00:24:21.279
So folks need to be able to build things for planet scale, but still be able to hold that tension.
00:24:21.359 --> 00:24:29.039
If you need to deliver something within a week, you understand what assumptions you're making and you know how to unwind them and turn it into a real product.
00:24:29.200 --> 00:24:36.720
So folks who are comfortable delivering under very different kinds of circumstances, but they know the depth of what that looks like.
00:24:36.880 --> 00:24:44.640
And a lot of tech companies now are also fundamentally changing their interview process to account for how software is changing.
00:24:44.799 --> 00:25:02.079
But again, like a lot of that is you're still looking for folks who want to dig into the details, want to take systems apart, are very strong communicators, and are not scared of owning end-to-end outcomes, even if it touches systems that maybe that is not kind of like their main area of expertise.
00:25:02.400 --> 00:25:08.799
This profile seems popular right now amongst a lot of your competitors and some of the big tech companies.
00:25:08.880 --> 00:25:11.200
So how do you think about winning candidates?
00:25:11.519 --> 00:25:14.799
It is, yeah, it is kind of like a fun talent war.
00:25:15.359 --> 00:25:25.039
But a lot of cases where we've won is we have access to a lot of problems that oftentimes it takes an enterprise years to get access to.
00:25:25.200 --> 00:25:33.920
Whether it's working across the US government or some of the largest companies in the world, oftentimes startups will not have access to these problems.
00:25:34.000 --> 00:25:48.319
And I think many cases where we've seen kind of like we've won candidates over others, folks have been motivated by these hard problems that cut across systems and working with like folks who have a very strong track record.
00:25:48.559 --> 00:26:04.559
So, like on the team, we have folks who worked at some of the best and some of the largest companies in the world and built systems like App Engine or Twilio's workflow studio engine, and as well as some of the other folks we worked with at Palentier.
00:26:04.799 --> 00:26:10.240
How have you thought about stepping into a new managerial like leadership role?
00:26:10.400 --> 00:26:14.079
How have you learned to lead teams and to rally folks around you?
00:26:14.559 --> 00:26:18.559
And maybe if you've made any mistakes or have any stories to share?
00:26:19.200 --> 00:26:26.400
So both Angela and I from Palantir days have all have had more people leads in addition to being ICs.
00:26:26.559 --> 00:26:35.279
And I think that is a strong kind of like tenet that we hold, not we we always we don't believe in just having middle management.
00:26:35.440 --> 00:26:40.720
Everyone in the company is a builder, so it doesn't matter that your level of seniority or tenure.
00:26:40.799 --> 00:27:00.559
Um yes, you might be people lead and in charge of helping growing others, but at the heart of it, you're still a builder, you're still tinkering with systems, whether it's if you're still writing code or prototyping or writing RFCs, we push for folks who continue to have that muscle as opposed to just managing folks.
00:27:00.640 --> 00:27:11.680
And I think that's kind of like been the model in which we lead people because people often want to see that you are leading by example, you can step in and they can trust you as a leader.
00:27:11.920 --> 00:27:13.119
And it's and it's exciting now.
00:27:13.200 --> 00:27:28.079
We're seeing a lot of people return back to writing and building code with basically a lot of the tooling that's available right now, where some problems may have been now too abstracted away, or like we're seeing like a lot of leadership return to basically building.
00:27:28.400 --> 00:27:31.920
What is your role distribution of a building versus a managing at this point?
00:27:32.000 --> 00:27:34.640
And the what point in a company's growth does it tend to shift?
00:27:34.880 --> 00:27:50.000
I guess right now, since we're a very flat organization, and would say the majority of the company reports to me and Angela, lopsided, but it'll be kind of like interesting to see how we scale and grow the team that we've built with us.
00:27:50.160 --> 00:27:54.160
I would say, yeah, we try to still pretty much active.
00:27:54.240 --> 00:28:00.559
So we had a hackathon last Friday, and basically a lot of us, yeah, participated, which is kind of like exciting.
00:28:00.720 --> 00:28:07.680
And I think being intentional around the time split, I think will be important as we grow.
00:28:07.839 --> 00:28:11.920
And probably at some point we will not have everyone reporting to us.
00:28:12.160 --> 00:28:12.319
Yeah.
00:28:12.480 --> 00:28:13.759
But no, that makes a ton of sense.
00:28:14.000 --> 00:28:16.720
So the agentic wave, as you know, is moving incredibly fast.
00:28:16.880 --> 00:28:20.480
I'm curious, where do you think the enterprise infrastructure layer settles?
00:28:20.559 --> 00:28:24.400
Do you think it's winner take all, or do you think it's a bit more fragmented than that?
00:28:24.799 --> 00:28:29.759
I guess there will continue to be room for a lot of different fragmentation.
00:28:29.920 --> 00:28:38.559
Obviously, there's a lot of folks who have made investments in their different hyperscalers and the tooling within that because the economics kind of like makes sense.
00:28:38.720 --> 00:28:44.240
But there are very much a lot of systems now that are being rebuilt from the ground up.
00:28:44.480 --> 00:29:02.480
For us, the the nice part about our infrastructure is oftentimes, like with enterprises, you don't have to blast your stack in order to use or start building safely with AI, which has been kind of like the main nice entry point for us because telling an enterprise you have to redo your whole stack is sometimes like a non-starter.
00:29:02.720 --> 00:29:09.920
But there's gonna be like an interesting wave right now where there's a lot of folks who think with the coding tools that they can build everything.
00:29:10.079 --> 00:29:17.440
So there's a little bit of an overcorrection of a lot of folks building in-house, and then there's gonna be like market correction.
00:29:17.519 --> 00:29:19.519
It's like almost like the reinvention of SAS.
00:29:19.839 --> 00:29:21.839
There are some things people realize actually, no.
00:29:22.000 --> 00:29:27.599
I mean, because writing code wasn't that really the hard problem, but like the last 10% is the hardest problem.
00:29:27.759 --> 00:29:32.400
Putting it in production and knowing that it's gonna scale or it's not gonna fail at 3 a.m.
00:29:32.640 --> 00:29:35.839
or under these certain constraints it's gonna recover.
00:29:36.000 --> 00:29:39.200
That is always kind of like has been the annoying problem.
00:29:39.359 --> 00:29:45.039
But I think right now there's like a lot of hype and buzz where everyone thinks they can build everything, which is which is great and exciting.
00:29:45.119 --> 00:29:54.240
But there's gonna be kind of like I think Q three or four big kind of like collapses or big large security kind of like problems.
00:29:54.480 --> 00:29:55.279
I'm already seeing it.
00:29:55.359 --> 00:29:55.519
Yeah.
00:29:55.680 --> 00:29:57.839
And then the market will naturally correct itself.
00:29:58.160 --> 00:30:04.319
And I think like, yeah, companies that have demonstrated that they've earned the right to be in this space will continue to be in this space.
00:30:04.400 --> 00:30:06.480
And then there's gonna be a lot of companies like will shut down.
00:30:06.720 --> 00:30:09.200
What are the like roles that you're hiring for right now?
00:30:09.440 --> 00:30:10.960
Any ending thoughts that you have?
00:30:11.359 --> 00:30:12.319
We're very excited.
00:30:12.480 --> 00:30:20.319
I think we've put up now a couple new exciting roles across the business operations side of the house and also the federal side of the house.
00:30:20.559 --> 00:30:29.519
We've done the hard work of going from zero to one across federal, and now we're looking for folks who are experts and can scale the machine with us.
00:30:29.680 --> 00:30:34.000
And of course, always looking for strong engineers and across Apply.
00:30:40.319 --> 00:30:40.880
Awesome.
00:30:41.119 --> 00:30:42.880
Well, thank you so much for coming on, Maya.
00:30:43.039 --> 00:30:43.279
Awesome.
00:30:43.359 --> 00:30:43.839
Thank you for having me.
00:30:44.000 --> 00:30:44.720
This was great.
