# Sycamore: Enterprise AI Agent Operating System

**Podcast:** alphalist.CTO Podcast - For CTOs and Technical Leaders
**Published:** 2026-10-29

## Transcript

Hello friends, this is the Alphalist podcast.
I am your host Tobi.
The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company.
We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast.
Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events.
Just go to alphalist.com to apply.
Welcome to the Alphalist podcast.
My guest today is Sri Vishanath.
And Sri was the first ever CTO at Atlassian.
hired right after the IPO and over six years he took the company from about 500 million to two and a half billion in revenue and engineering to over 7 000 people he left at the peak in 22 and this spring for the first time in his life he became a founder he's building a company called sycamore an operating system for enterprise ai agents with 65 million dollar in seed And he is CEO and I assume CTO at the same time.
Sri, welcome.
I am excited to be here.
Thanks for inviting me, Toby.
Maybe like as a first question, I always start with that.
Like how, I mean, you're now CEO, right?
And I had that hypothesis that you're also the CTO at the same time, which is true for many US companies in Germany and Europe.
You don't see it that much that like CEOs are technical.
So I assume you are...
a nerd or at least a geek, right?
And how did you become one?
Like why did you get addicted to computers?
Yeah, no, that's a great question.
So I've always been a techie from a long time, undergrad in engineering, masters.
At some point, I also did my management degree just to get a broader sense of what it is, but I've always been...
deeper in technology.
And it's been such an exciting time over the last 20 years to see the cloud transformation, mobile transformation.
And now AI is literally changing everything everywhere.
So even in the last six months, you said as a CEO and CTO, in a startup, you literally do everything, including taking out trash.
So anything that we need to do to make it work, we make it work.
So that's my role.
Then what do you have to make work right now?
Like what is your current biggest challenge?
I guess, I mean, building up a startup, like for me, this is like the most exciting time when you can fill in multiple roles that you didn't fill in your company.
What is the role you're filling right now?
Essentially, we have been building for a year.
We have many customers in production, lots of customers that we are working with.
We work with large enterprises.
Lots of customer meetings, customer interactions, go-to-market, lots of hiring.
We are growing.
We are adding lots of humans and agents.
So lots and lots of hiring, lots of interviews, takes up a lot of time.
And of course, building.
I've always been building.
In fact, for the first six months, I wrote a lot of code.
I mean, when I say I wrote a lot of code, my agents wrote a lot of code.
You generated some code.
Okay.
There you go.
But that's the future.
We'll talk about more on how it's all going to change.
But now I focus a lot more on go-to-market and strategy and just overall technology architecture and product direction.
Okay, so you're still deeply involved in tech.
But I mean, the sales role, like the technical founder is always a very important piece, especially if you have a very technical organization like yours, right?
Totally.
Yeah, no, it's very important, especially when things are changing so fast.
Literally every few months, the whole landscape changes.
And as an organization, we need to be changing and we need to be adapting to whatever is coming.
The new models come in, new frameworks come in.
We implemented recursive self-improvement.
There's a whole bunch of things that, and the level of chaos in the system is much higher.
So anything that...
we need to do to make sure that we can actually deliver in the changing environment, we do and adapt.
And right now, how many people do you have in the company and how many of them write or generate code?
So we are about 25 people in the company.
We'll be at around 50 by end of the year.
We are hiding a lot.
I would say none of them write any code themselves, but...
All of them write code because of their agents.
Most of them are engineers.
We are based in Palo Alto on the Stanford research campus.
So we have a good team from Stanford and PhDs and really strong team in terms of we built the whole stack, including infra.
We built all the AI.
We call it the operating system because of all the services and applications that runs on it.
And also the agent layer, we call it the agentic apps, which are agents, workflows, and traditional applications with front-end, back-end, and dashboards.
And we can build all those autonomously.
So there's a lot of surface area to build in terms of what we need to achieve.
Basically, if I step back, our vision is to build an agent operating system for large enterprises, which basically means we are reimagining how software is done for large enterprises with agents.
So what we had to do for this is we had to take the best of the SaaS world and all the customization that all the consulting and SIs were doing previously and trying to bring that into enterprise without bloat and also how do you get that with a compounding value, which is what we focus on.
And which is why we call it the agent operating system, because we can deploy lots of agentic apps on top of this platform.
So is that basically a model view controller framework that is, or something like that, like some deterministic form of agent build systems that can, again, interact with AI?
Or is it a bit like an air table for agents?
Yeah, so what we have is a super easy way with natural language to build custom SaaS solution for large enterprises.
So all the features, including, for example, I built Jira and Confluence, all the enterprise products are there, and VMware and Sun Microsystems, a bunch of places.
And every large enterprise expects you to be secure, compliant, auditable.
So features that the enterprises need.
Our autonomous builder automatically builds that into every single app that we build.
And building is the first part.
And once we build, we can also deploy.
And the deploy goes through the same CICD pipeline that the enterprise grade that customers can customize and have their own security standards and everything goes through the CICD pipeline.
We deploy it into either our managed cloud or customers VPC.
How do you do version 2 and version 3 and version 50?
So that updating and changing afterwards is our true value prop.
If you look at the history of software, as soon as software is deployed, it starts decaying because requirements change and it doesn't do things and there's issues and it takes a long time to change the software.
Our premise is because we have the full loop closed, we can be changing and instead of decaying, we actually grow and become better after we deploy.
Some of our customers are in V50, version 50 of the application because you can easily change it and it goes to the same standards and there's confidence that we can write for agents.
We have evals that runs for test cases, verification, security, auditing, all that happens behind the scenes, under the hood.
A human is involved building the agent and the product and the agents are rated as far as I understood it.
Like you kind of get like a grading, like for the quality of the agents so that you kind of can judge like.
Correct.
But the rest is human built basically.
So there's no self-improving loop.
Like, hey, have you thought about this?
Like, this is what I haven't.
Oh no.
So the way we want the humans to operate is like a business owner product manager and not as an engineer.
Right.
They should figure out what the problem is.
How do you make sure that they can solve the right problem in the company and interact with our system using that?
And we do have proactive intelligence built in.
So every so often it analyzes the system and that's fully configurable and comes back with, I can make this update.
There's these five things that's being done manually.
I can write this software agent.
and it automatically closes that loop.
So we do have the recursive self-improvement built in at various different levels of the system.
Okay, interesting.
But maybe before we dig deeper, let's maybe dig a bit into your Atlassian history because it's kind of an interesting company and also I guess you learned a lot also through this whole bump from 500 to 2.5.
That's quite a lot and managing 7,000 engineers.
Atlassian ran 14 years without a CTO to technical founders.
Then you joined.
Why did the company at that time need a CTO?
What did you add?
Yeah, so there are lots of things that were really good at Atlassian.
And it's still good.
The culture is really good.
People are amazing.
They had built a product that most many companies used.
And it was always on-prem.
So what they wanted to do at that point is to move to cloud, right?
Which was my main agenda in terms of my joining is, can we make Atlassian a cloud company?
So, and I had worked previously at a few places which were cloud native.
So my charter was, can we build a cloud native company?
And the way I approached it is to make it AI native, we have to change the operating model completely, right?
It's great in terms of you support 10 different databases and lots of different types of UI.
There's lots of different ways of doing this.
When you move to cloud, you don't have to have all those.
You can support one database and run it, but then the running piece requires a lot of different skills with SREs and making sure that you have pagers.
So what we did was we essentially split the organization into on-prem and cloud.
And we rebuilt the whole stack and did a massive surgery to move what we had and build everything on cloud.
And we went AWS native at that point.
And we built a lot of services.
And as we added services, we could hire people to make those services much better.
And we created a platform with all these microservices plus all the products.
And we also had a bunch of acquisition, including Trello and a few others.
So we brought it on to the platform.
And if someone would now come in as the CTO, she or he would most likely say, hey, this is horrible.
It's a mess, right?
I think.
And this is kind of interesting how things come in waves, right?
Totally.
I mean, that's why you said software decays as soon as you build it.
And in fact, this time it's even worse because… If you zoom forward five years, the way the software stack will be is completely different from what we have learned and built in the last 20, 25 years.
I guess AI will ride on the wave of all the previous waves, right?
Because we have cloud, because we have mobile, just the adoption is much faster on AI.
However, the stack that we have to build and the processes that you need to have and how you run your...
engineering and rest of the company completely changes.
And it's not going to be the same in the next five years.
And which is why I started Sycamore because I was a VC happily investing in AI companies.
But this transformation is bigger than anybody can imagine.
And it touches every single company, every industry, every human.
So the kinds of things that we need to do in the next five years in terms of transforming these companies is massive.
So are you with Elon Musk who says, like, in a few years, we'll all watch a customized video stream instead of any software.
And this will be what we're interested in.
And this will solve all of our issues and all of our needs.
And we just express what we want and it will be there.
Or is it?
I do think there's general consensus here saying.
It's just a timeline question, right?
AI will keep getting better and better.
So it does solve even.
just compare from last year to this year, you can literally say, go to Cloud Code, go to Codex and say, build me this app, and it'll build you the app.
It's amazing.
And it won't have any issues.
At least not on the first side.
I think software slop even degraded quite a lot, right?
With Fable, etc.
Exactly.
So it's going to only get better and you can be able to trust like simple apps.
And that all works for like small, medium companies and things that you're trying to solve.
The large companies have a much bigger problem because they have compliance, they are auditing, they have processes in place.
They have lots of people doing things.
The change management from where they are to where they have to go is actually massive.
And that is not easy to change at the speed of AI.
So what we do is because we have a self-service platform, our goal is to be able to move that faster than any other products that are out there.
But I do think AI is going to change a lot.
And I'm in the camp of like, it's going to help move our focus into a different areas where you can actually do more things, maybe watch TV screens.
But also if you want to be, you can actually invent.
new discovery, new software, new problems solving.
It's going to give us a lot more leverage overall as humanity.
So maybe like a little bit of a counter question on enterprise or provoking a little.
I think in many enterprises, so what you're basically saying or what I hear when you're saying that there are processes, there's compliance, et cetera, then a lot of this is human made.
And a lot of the complexity that you see in organizations as human-made, where you have the different levels introduced or the hierarchies introduced, who basically protect themselves, who protect their own creation to somehow have control over it.
I think that's, in many cases, the goal to kind of stay in control, stay in charge, right?
And in this AI world, Doesn't it cut through that?
I mean, isn't it such like looking at, for example, the Evernote acquisition for Bending Spoons, right?
Where everyone was let go and the whole stack was basically cut into small pieces and distilled into a new setup.
Isn't that the end of the enterprise as we know it as well?
No, I mean...
You can cut everything and have one person just manage it, maintain it.
But if you want to really innovate and build the next generation things and make it more adaptive to the next generation of software that's going to come in, it's going to change the shape of the software that exists in the next five years.
You do need humans to be able to express what they need.
Because the translation layer between where AI stops and what humans actually need, there's a gap there.
the last mile gap.
So that I think will exist even for the next several years.
And to be able to figure out, I guess, how do you build a business?
The reason we focus on all the non-technical users in a company is because what will happen is engineering, you don't need as many people over time.
Small group of really talented engineers can build a lot.
The question becomes, the bottleneck becomes, what do you build?
How do you remove processes that existed previously?
How do you make sure that if you have 10,000 people, you only need 5,000 people or even less at scale when you deploy these agents and software?
How do you manage the change?
Because those become extremely important because there are some choices that companies have to make.
Do you want to reskill the people?
Do you want to not have the people?
Do you want to have them build something completely new and work on something new?
All that.
is in the next five to 10 years, right?
For all these large companies.
But it also opens up opportunities, right?
For companies that are much more forward-leaning and tech-leaning, they can adapt and make these changes.
And I talk to most of the Fortune 100 companies and many CTOs, CIOs across different industries and companies that are like thinking, this is going to happen.
I'm going to make the changes proactively.
will be in a much better shape than people who are like, I don't think it'll touch my industry.
It's not, I need to do some AI, let's do just the chat interface.
As long as they jump in the right moment, right?
I mean, that's also really the question.
Like, is it now the right moment to invest or do I rather watch for a while to kind of hit the right moment?
But I think there's no real...
There's no good moment, right?
There is no good.
In fact, no, it's already too late, right?
So they should be jumping in right now if they haven't already.
And the reason is you'll need some time to learn, right?
You want to experiment a little bit before you take on, okay, let's transform the whole thing because you want to have some agents running.
You want to have some autonomous agents.
And that's why we have this thing called progressive trust where we don't want our customers to trust our agents on day one.
In fact, they shouldn't trust any agents on day one.
And the agent should gain trust over time.
And our agents go through a journey where they gain trust.
And at some point, they become fully autonomous.
And they're never autonomous on day one.
So that's the kind of things where when they experiment certain things, then they learn what they want to do and what the capability has.
That also trains people, especially the people who make decisions on which directions to go.
And as soon as they have those decisions, then it's a lot easier for them to make bigger and bold changes afterwards.
So that's also how you better teach humans to do something, right?
Like, I mean, independence who deserves independence, I'd say.
Like giving full trust from the start is something that humans often do, but it's not always good, right?
Exactly, exactly.
Humans get referrals and you're like, oh, you've done this before.
There's some...
aspect of, okay, I can trust this person because there's something behind that.
Agents don't have any of those.
So you better go through the place where you can trust this agent because it's been doing this thing properly for the last six months and then it can go autonomous.
So your agents have CVs.
But maybe let's step back to Atlassian and go through that journey as well.
Where if now you would have...
Let's provoke a little again.
I mean, 7,000 engineers for an issue tracker and a wiki?
Is that seriously?
It's also the most loved by some and the most hated software by many others.
What did they all do?
What did all the people do?
Or do all the people do?
And how many would you need today if you would take it over again?
Yeah, there's lots of things here.
So let me try to break it down into a number of different pieces.
So when we scaled up, running a large-scale SaaS company, especially when you have customers in 200 different countries, and you have a platform that has multiple products in place that needs to have a unified set of services, and it's somewhat fully self-service, can go all the way from you starting to fully customizable all the end.
I think people underestimate what goes on behind the scenes to be able to run that successfully at like four nines, five nines kind of liability and all the things that comes behind in terms of non-engineering side of being able to build the right things, support services.
And also maintaining all the legacy business that was there, right?
Exactly.
Migrating and we had to migrate.
It's non-trivial, right?
People don't realize that it takes a lot of time and effort to build it, right?
And maintain it and run it.
So we were always at a place where whenever we hired people, we always had more backlog to build because we could move faster if we had more people.
And the way we had architected was we had different services and each service could have a team of like five to six people who can work on that service and make it better and add features.
But there's also a layer of like, coordination of what do we need to do and the quarterly planning and the yearly planning.
So we spent a lot of time on figuring out what to build and how to build it.
And literally all of those people were pegged to the maximum in terms of what and how to build.
So I don't think people underestimate what it takes to run.
And after I've left, I left four or five years ago.
The next CTO came in, they also built out a number of AI.
So they've grown over time, even afterwards, and they've done a phenomenal job in just adding more AI and everything, right?
So it's not non-trivial on the first part.
The second part is AI is going to change everything, right?
So the shape of Jira that exists today, and Atlassian knows this too, because I have no inside knowledge.
I'm an outsider now.
I see Rovo and other...
AI products coming in.
So they do realize that future is AI.
And I do talk to a few people in the company.
So they do realize it's AI and the shape of Jira changes significantly, especially for small companies like us.
Because we build autonomously, we don't use Jira in the shape that it exists today.
We don't need to say, oh, let's do a three-week sprint cycle.
Let's create these 10 tickets.
And sometimes it's funny.
When you ask Claude or ChatGPT or Claude or Codex to write a plan, it says, oh, it'll need three engineers for three months.
And we're like, no.
Yeah, and then you do it and it needs like five minutes.
You're doing it today.
Exactly.
So the world has changed significantly in that sense.
So the Jira that existed five years ago, 10 years ago, is not the Jira that people would need in the future.
But there's still a need for having a central source of truth, irrespective of Jira, right?
Let's step back.
So there are, in a company, there are certain objects in a company, certain source of truth in a company that needs to be saved in a database where everybody in the company knows, not just humans, but also agents need to know to go and say, if I want to know who our customer is, I need to go check this database.
If I want to know who, what projects are running, what the status is you need.
So I do think there is a way of architecting for the next generation of things where, There is this set of databases.
How do you expose terms change?
We had APIs, we had UI, now there's MCP.
So that might change.
MCP is still the same kind of interface, but you still need to architect and design and figure out what you need in the back end.
The good part is AI can do a lot of those.
If you start from scratch today, for example, we started from scratch.
The way we run the company is very different from any other company that exists.
That started like two years ago.
Or either they haven't changed yet, or if they've changed, they've looked like us.
We are pushing the boundaries on...
Literally, we don't have anybody in ops doing the same thing two times.
So we always automate everything across everything non-engineering.
Engineering, we are building an autonomous builder, which means...
We better dog food what we do.
I assume in your own software, basically.
We have to, because if we don't trust our own software, we don't want our customers to trust our software.
So we try to do complete development autonomously.
It's still not solved.
So there's still bottlenecks on a number of things that we are trying to unblock.
And that's the research that we are trying to do on all things.
progressive trust and making sure that we push the frontier.
How do you solve harder problems than the frontier models can solve by having multiple models?
How do you fine tune models for a specific use case so we can have smaller models that's much cheaper?
And in fact, we do some interesting things where if you do the same things multiple times, we can rewrite that in code so that the cost of operations for that is much lower and it's auditable.
and it's repeatable.
So we try to get as many things into code as possible, which needs to be auditable, repeatable, and needs the non-probabilistic kind of deterministic output.
That means I know the answer to the next question, which is if you were inheriting Atlassian now, what would be the one thing that you'd never build again?
Query letters, processes, the whole apparatus.
What's the ballast, basically?
And I guess the answer is everything, right?
It's a lot of things will change.
And Atlassian is already trying to change that.
The thing is, the customers who use it can't change fast enough.
So even if Atlassian completely re-does the product today, customers will take five years to be able to move to this new model.
So that's the thing that they'll have to navigate.
For us, we start from scratch, and I'm not trying to build what Atlassian is building.
What we are trying to build is a completely new way of building software that can build operations, automate operations across the company, various different products.
So you're building a builder for Atlassians for companies to build Atlassians.
We are building a builder for custom SaaS, exactly.
People can build custom SaaS solutions because what happens in software is most of the software that you buy has like 500 features.
What you need is literally five features and you don't want to pay for 500 and all the complexities of 500.
If you want five features, we'll build you five features that's exactly the same grade and does everything and data never leaves your VPC, right?
So, which I think is a big value prop and the way, the direction that I'm seeing is there's no SaaS that works well in the new AI era because what has happened is all the previous SaaS products, have bolt-on AI.
So they built ChatGPT into it, and now they're trying to fit some things into it.
Whereas our platform is completely agentic ground up.
You build the software autonomously.
The software itself has agents, workflows, and whatever you need, front-end, back-end dashboards, all built in.
And you can manage it, maintain it.
And it also proposes features that would make you more effective.
And if we can get that working really well for large enterprises, that's like the future of how living software should be.
And we close the gap between what LLMs can provide.
When LLMs get better, we can solve even harder problems and what customers need.
And we still need some FDEs.
We still need some last mile customization, not because our builder cannot build, but to figure out, I guess, what to build and make sure that it builds correctly.
So we don't need...
lots of people, but we need some people still.
And that's the gap that will close, I guess, in the next few years and become fully autonomous in terms of what we can do.
But we are in the direction and lots of our customers have already gained benefit because of that.
Well, then the ultimate company of the future be...
company of agents where agents tell the humans what to do?
It's already starting to happen.
No, no, no.
You seem to be laughing, but it's actually starting to happen.
In fact, many of our agents do things and at some point delegate some work to us because they are like, oh, I can't log into the system.
Can you log in and give me this?
And I log in and give it and then it takes over from there.
Yeah, I mean, that's how the workflows also.
private life, if you just deal with Claude, etc., like the change, right?
At a certain point, you see yourself just authenticating and being human in the loop on certain things.
And I could imagine that this even becomes bigger.
Yeah, what happens is when this becomes bigger, the bigger problem later, especially for large companies, is how do you make sure that it's doing the right thing?
So trust, but verify it.
The verify part becomes extremely important.
So what happened was we built our first product, which is a builder, Sycamore Forge.
And people love Forge.
They're building it.
And we also build governance into it, all things that guard our agents.
And all our customers are like, can we use Guard for all our agents that we build?
So we pulled it out and created a second product called Sycamore Guard.
And Forge and Guard work together in terms of one builds the other guards.
And it seems like Trust but Verify, I guess, is the future in terms of how we need to do.
from my perspective really initially came from like a PLG angle where the product was growing because people just downloaded the trial and were using it.
Like I remember myself like really downloading that JAR file, right?
So no sales calls, nothing, which is like really very close to my heart because I hate the get a quote button, right?
And you basically sell governance and trust, and it's more like a CISO conversation, right?
Do you think that PLG ultimately is over, like the PLG phase is over, and you now have to be enterprise to survive?
Or where does that come from?
Yeah, so Atlassian did a phenomenal job.
I guess I was there for...
six years six and a half years most of the revenue i guess on plg completely we never talked to our customers even large customers did we had system integrators and channel partners who did revenue outside that but internally we were starting to grow when i left we were starting to grow our enterprise team now they have an enterprise team and they're moved to standard selling processes but for me i guess the lessons that i've learned is we need to build a product that is actually self-service after it's deployed in the customer's environment.
Because once we have Forge running, the employees need to wear the product hat and to be able to describe what they want and build what they want, which is what we focus on.
And that's starting to work really well.
So the sale motion, the land motion is an enterprise sales motion, but the expand motion is fully self-service.
which is how we have designed Sycamore.
And do you think that this will persist long-term or will you at a certain point also pick different angles where agents can sign up to get the tool for the company that needs it?
I'm sure we'll change.
The thing right now is there's not many standard protocols.
to interoperate with other products and other systems outside.
Payments is starting, A2A is early.
So the standards are still early.
And we try to be, even when we build, again, just like the previous cloud era, there's a lot that goes into build a system like what we have built, right?
Just if you want to build and run an agent, you need to figure out how do you run a sandbox?
Running a sandbox is actually in its own a full job.
Because you don't want to give keys inside the sandbox to the agent.
You want to keep it outside.
You want to make sure that you don't let it connect to everything else and hugging face by default.
So you need to make sure that you default, deny network and only give access.
You want to be able to track everything that it does just in the sandbox side.
And then there is all the new dimension of issues that come in on what is the agent doing and sending.
So you want to be able to do, is it sending PII data?
So you need all the security aspects.
This is probabilistic, right?
In the deterministic era, you could actually do security somewhat easier and guard it easier.
Now it becomes an even harder problem with a new dimension of it's not the same string that's coming in.
If it wants it, credit card, it doesn't have to send with numbers.
It could write, spell out the numbers and send it out someplace.
So the...
The guard that sits there needs to figure out, wait a second, it's spelling 1, 7, 5, this looks like a credit card and we need to stop that.
There's so much new directions that we are still scratching the surface of what needs to happen, both in terms of the whole building, running, and managing enterprises, like the agents for enterprises.
And that's why even enterprises are cautious because there's lots of wipe coding platforms that lots of easily, oh yeah.
my employees built this thing, but I don't know what to do with it, is I think where we are at this point.
All that will get solved in the next five years.
And then it comes to the point where can agents talk to some other agent in the next company and to negotiate partnerships?
But that's still far out because we still need protocols and standards and trusting that happens.
That's why when we started, we started with the trust as the main pillar.
Most of the time that we spend is making sure that the agents that we build can be trusted and invest a lot of time in verification, validation, all the guarding piece.
Because my belief is governance, the more governance and trust that you have, the faster that you can go.
So governance gives you speed.
So we spend a lot of time to make sure that that happens.
And then you also want to have these agents imbibe values of the company and how you work and what.
kind of language you use, all things that even in the last six months, I guess, OpenClaw and a bunch of other ones came in with Sol.md and things like that.
What's that for the large enterprise?
So we spend a lot of time on what's the values of the company and how do we operate in a company that feels like it's like an employee.
So we have different types of agents that we have and different characteristics and they do slightly different things.
It's actually useful for different purposes.
So just stepping back, there's a lot that goes on just to be able to solve a problem.
Brute force, you can solve one thing, but to build a platform that can solve a number of problems autonomously, we are still early days for the whole industry.
Yeah, absolutely.
And this is also the stuff that, I mean, you can solve with agents, obviously, like you can use clause, right?
But you have to have like an idea of...
the core principles that you want to apply, right?
And also some sort of like a technical background to at least build the taxonomy for everything, utilize the right concepts in your core platform, right?
So that you basically create that deterministic layer, which can be fed by probabilistic tools, right?
Exactly.
I think you're pointing to the very important things that the large enterprises should think about is systems thinking, right?
How do you step back and look at the company and the things that you want to automate as a system and figure out what pieces do you want it to be common?
What pieces do you want to automate?
What do you think is high risk, low risk?
Just understanding the system and thinking of system before you build anything and design that system is extremely important.
In fact, people miss that and say, oh, I want to solve this problem.
There's a workflow.
We want to automate that workflow.
It gives you a little benefit, but the actual benefit comes from, oh, if I step back and actually create a common knowledge base for the whole company, it solves 10 other problems and becomes a base for what other things can come in.
So what we do with companies is we actually spend the first six weeks, eight weeks called co-design.
And we do the systems design thinking on all things that they could do, not that we have to do, but...
That, I think, is a very important portion of how you want to think through the next few years.
So the good old forward-deployed engineer, basically.
Yeah, I think there's a confusion of what forward-deployment engineers do.
Because forward-deployment engineer sounds like you go in, you fight battle, and you solve a problem, and you come out.
And it seems like that.
But actually, the most valuable piece is the system design part on...
can they step back and solve a problem in a way that actually makes it work well for not just that piece, but gives them a long-term moat in terms of how they are solving.
And that, I think, is rare in terms of what I see in the market.
Yeah.
I mean, systems thinking, I think, is a rare skill that you don't find in many companies with the right strength, right?
The right amount or right.
on the right level to actually take decisions on how to build the overall structure.
And if you look at what you have created, what is then the most important building block that your own systems thinking?
has engineered?
I mean, obviously, the CV of agents understood that's important, but if you come to the technical level, what are the technical building blocks, the technical core concepts that make your system better than, I don't know, Rovo or Replit or whatever, Airtable?
Yeah, so what we have done is we have made our system extremely modular and We have a number of these core systems and libraries that we have created that gives you this enterprise-grade features.
And those are tested, validated, and gives you benefits of when you're building, it can pick the right set of building blocks.
Think of it as Lego blocks, right?
So we have built a number of Lego blocks that are tailored towards building a SaaS-like solution for large enterprises.
And some are domain-specific and some are generic, but we have a framework where we can quickly build many of those building blocks.
And the building blocks are at various different hierarchy.
So there's building blocks for Sycamore.
There's a building block for all of the enterprise.
There's a building block for a department.
And then the solutions come on top of it.
So that's why we can let you change completely.
And how it works in the backend is...
If you look at our system, if you open the hood, you'll see that we have a pipeline that's fully customizable.
We have structured formats of where you can add more things pretty easily.
We have libraries that are very well designed.
We have APIs and services, platform services that are easy to use.
We expose CLI, we expose APIs, traditional APIs, and MCPs, both.
at the lower-most level and also at the app level.
The agentic app that you build also is an MCP for something else that you want to use.
So we have designed it so that it's modular at every level and it's like a fractal.
It looks similar as you go up and it just does more things, but you still have an MCP at the end of it, which makes it easier for us to build, add on more things and build the systems and refactor.
if you need to change direction or something, which is what gives us the malleability of large software.
And what are the most important technical pieces and what's your base infrastructure?
I guess, like, I don't know, Kubernetes and whatnot, right?
Yeah, we are fully Kubernetes-based.
And what allows us to run on any cloud?
or run on a customer's VPC, right?
So that's made it a lot easier.
Then we also control the whole stack, which means we run our own sandboxes.
We can, like, the identity, agent identity is actually a really hard problem in itself.
And we have solved it in a way where we don't just give it permissions.
We do, like, time-based tokens, where if it needs to operate and do some high-risk job, it only gets it for, like, five seconds.
So zero trust, basically.
Exactly.
So it's zero trust across the board.
And that's a lot of engineering, hard engineering work that happens.
So there's a number of hard engineering jobs that we have done.
Then we have also pushed, and we don't publish benchmarks.
We don't compete in the large benchmarks.
Maybe at some point we will.
But our builder can build anywhere from six hours to six days, even more sometimes, like two weeks.
which means the long horizon tasks, it's never easy.
So we have done a lot of research in terms of how do you make sure that you can actually build these kinds of complex applications that runs for hours and days together.
So there's a lot of AI research that we have done during that.
And of course, we have spent a lot of time and energy on the recursive self-improvement because it sounds easy, sounds like fancy, but to actually get it work in a general mode for all use cases.
It's not easy.
Not that we have solved it fully, fully, but we understand the shape of what needs to happen.
And there's still human in the loop because we suggest something and human has to approve it.
So there is some checks and balances in place, but that's something that we have actually closed the loop on, which is extremely important in the long term.
Are there any core languages that you'd like to use or how much freedom do you actually introduce in the times of agents that can write perfect code?
Do you think...
Code still needs to be read, do you think?
Or is it basically code reviews done by agents?
So is the code an artifact now?
Yeah, we don't read code for the most part.
We don't read for the code libraries that we build.
We are extremely careful for doing it.
But for most of the apps, we don't do it.
But we do have lots of review agents.
We have our own review agent that we use.
We use best of breed.
We also optimize for...
We write evals for the agents and we run the evals at different stages and also in production.
We have a same CICD pipeline.
Our agents deploy into dev staging production.
So it goes through the same cycle that you would go through.
You can go in and checkpoint.
Human has to approve it before it goes into production.
So we have made it so that you can have this workflow that's fully customizable and human in the loop in many places.
And as you gain trust, you can make some of them autonomous.
So I do think as we go towards this, many of them will become autonomous in terms of you don't need to keep approving the same things as you go.
Our system also gives you a video evidence of all things that does change.
So we don't look at code, but we have spent time, a lot of time on the intent of what you need to build and the verification piece and the guarding piece, which is important.
We do expect the agents, the LLMs to improve significantly so that the middle piece of actual building, we'll do the right things based on the constructs and shape that we have in terms of the framework.
And now with a tiny startup, how do you decide what you build?
Is that fully customer?
I guess it's not customer-directed purely because customer can also give you often a wish list, but that doesn't result in good products.
So is there a roadmap, a planning process?
How does that process look like for you?
Or is that already like ballast again?
No, this is the biggest challenge I have.
And generally, most of the product leads and CTOs have because it feels like you can build everything.
It just feels like, oh, yeah, I can just say it and it'll build everything.
But actually to build a production, to get to 80%, easy.
That's actually true.
It has compressed.
But to get to a really good solution, it's actually really hard.
So prioritizing and making sure what we build.
is an industry problem right now.
And it's a problem for me too, in terms of how we constrain and focus on what we need to do.
So that's like, we understand that's a problem.
I think it is a problem.
We try to figure out, I guess, every, we do weekly planning cycle.
In fact, we do daily planning for the most part because the things that we decide in the morning, we ship by the night.
But we do, we have a weekly plan.
And in the weekly plan, we explicitly list all things that we should not do this week.
And we get a lot of input from our customers, and that's been extremely useful to shape the product.
But we don't just take what they say and build it, because we need to put it into our framework of how do you build these Lego blocks?
How do you make sure that it can solve not just their problem, but a broad set of problems?
So we take it and use it as input.
but not exactly do what they want.
We might do the exact same thing for them because it's a business problem for them, but into the platform, we make it somewhat more generic.
I think the real answer on this, like looking at this problem, the real issue has been there for a way longer time.
I think in many companies, the engineering org that was always slow was just a perfect excuse.
Exactly.
On companies not to think about their business.
Like, hey, we're waiting for this migration to come down from this monolith to this move databases from A to Z or whatever.
Right?
And I think in many companies, this was shadowing the fact that the company had no idea.
Totally.
And also, product managers had some time to go do research, come back with, ask some people.
Now there's no time, right?
So you decide in the morning, you do it in the night, and next day it's like, what do I do now?
You can do 10 things, which one do I do?
So I think that's a problem that we haven't solved or nobody has solved yet.
Mostly because we know the direction of where we are headed and we have a vision of what we need to solve.
For a startup, it's a lot easier because we have a North Star on what we are trying to solve and we solve towards that.
For enterprises where they have to solve a problem where they need to coordinate with multiple people and things like that, that's a bottleneck.
I think even the communication, especially with bots in Slack and general bots, personal bots that come in, maybe there's a communication speed up that happens which can also solve some of these problems.
Some of these problems, but I would say the real issue then is product market fit.
that you have to solve, right?
Correct.
I mean, the bottleneck flew from, like, went from tech and engineering to kind of product people and then back to the client and the client doesn't want 50 features a day or isn't able to also consume that, right?
Yeah.
Yeah, so consuming on the side and also just, is this what you want?
But the good part, there's a positive there is like, you can quickly iterate towards what they really want because it used to take a long time.
Now, Within a week, you can get to a place where they say, ah, that's what I want.
The first version was bad, but this version is actually what I need.
So you can iterate fast, but how do you scale up if you're targeting a large audience, just the marketing and the go-to-market?
That, I think, becomes a bottleneck because then you have lots of things to sell and you don't want to be changing your messaging every day.
Right, right, right.
And then the client becomes the problem because he can no longer...
consume what you're sending, right?
Exactly.
It's too much, right?
It's as if you're flooded with messages, just that you're flooding with products and that could become a problem.
At some point, it'll also get solved by agents because agents is the one consuming it and humans on the other side is like, solve me these five problems and agents are like, ah, I got your solution.
Here it is.
Let me enable this feature for you.
As long as the human are able to express their five problems, right?
I mean, that's also often the case that this is not entirely clear.
But quickly, from this to the engineering org of the future, what do you think now directing a very small org and having this product market issue already, if you imagine an engineering org in 28, what will the human to agent ratio will be?
Will there be a 50-person software company?
Will there be a 7,000-people company still?
How do you imagine that?
On the engineering side, let's talk about just engineering.
I think what will happen is, right now, I guess our ratio is 1 to 10.
So every engineer at least has 10 of these sessions always running.
Plus or minus, depending on the kinds of problem that they're solving and things like that.
Maybe five, maybe 15, depending on how easy it is to scale a specific problem and how we can parallelize.
And that's what they are interacting with.
Underneath, there may be workflows and other things that may be running a lot more of these different branches and work trees that can do a lot more things.
So I think that only is going to increase as long as you know what you're building.
Again, the challenge goes back to how do you know what you're building?
If you have clarity on what you're building, man, you can go much, much faster than anybody else.
But to know what it's doing, you need to do a bunch of experiments and it's somewhat single-threaded because you need to make decisions as humans in terms of what shape you need for the product.
So that happens.
But in a larger organization, I think it becomes, if you have 50 people, and you have a distribution of work that happens, you might be able to do the same work with 20 people or 10 people that are organized well and have the right set of agents and the right system underneath.
So I think you need less people to do the same job, which is quite obvious.
The other thing that happens is the reason we had hierarchy in an organization with six levels of hierarchy, if you have 7,000% org, You needed that for various different reasons, planning, helping organize, communicating back and forth, all that.
If agents can do much better and you as a leader can literally communicate to every single person in the company using your agent and their agents can consume it and they get a personalized message, then it eliminates a number of layers in between.
So you could have a much flatter org and a much slimmer org.
to accomplish the same thing.
And then you need to figure out, how do I shape it?
Do I build more or do I build with less people?
So that's a challenge, I guess, question for the executives who will have.
So do you believe in a 7,000 engineers organization in 28?
I mean, today there's companies that have over 100,000 people.
So even if they...
figure out, I guess, how many they need to be able to accomplish this.
I'm sure there'll be companies over 7,000, but what they do and how they're organized will be completely different for those.
Their companies, all the big ones, the FANG ones are like 50,000 plus people.
You're right.
And what do you think should a 30-year-old, like if you could send like an advice to all the young engineers out there, a 30-year-old engineer learn this year just to be paid in 28?
I guess you already told me the answer.
It's system thinking.
System thinking.
Exactly.
I think to get the systems thinking, you need to build some systems, like some subsystems.
So I do think learning computer science, just software itself gives you this systems thinking and how you think about solving.
Even a small problem, you need to organize it well.
start thinking about larger systems because that's what will happen because your agents, all the engineers, even if you are like just out of school, you're a manager now, right?
You're a manager of agents.
So you need to figure out how to manage 10 of those, whether it's humans or agents.
And then how do you think about it as a system so that you can figure out to better organize and better solve the problems.
So become more product managers, become more systems thinkers.
I guess figure out how to manage a larger set of agents is my advice.
Worst decision you made at Atlassian?
Not the diplomatic version.
The worst decision?
I actually wrote a blog about this.
So what happened was when we were migrating these customers to our cloud instance, We migrated the customers and then we started building features.
And that was a bad decision because we should have paused this rate at which we added features right after we migrated customers.
Because what happened was the stability for the next few months was terrible.
And I called it the 5 alarm fire and I wrote a blog and we corrected all those.
But it wasn't great.
three months because it was so much pain to stabilize the system and making sure that we can scale up and then we could add features.
But all part of learning.
It was a massive project, but it was definitely not the right call.
Yeah, so I have to take a look at that blog and see what you wrote back in the day.
Search for five alarm fire.
Five alarm fire.
Okay, very good.
Then Sri, I still have a little surprise for you, which is also my closing question and goes hand in hand with the question before.
I actually found from back in your early days, I found an old Gyra instance.
on a bare metal machine that I have from back in the days self-hosted version 4.4 running on a single machine and it contains exactly one ticket which only has the title Migrate to Cloud, status open created 2015 by you and when I now click resolve imagine it takes us back to the year 2016 And it's your first week at Atlassian.
And we can now watch young Sri for a while.
And yeah, like basically like really getting into that founder-led company and getting your hands dirty.
And now you could whisper something into your younger self's ears.
What would you whisper?
Wow, that's a good question.
I think we made bold decisions in the first.
three to six months where we forked the organization into cloud and on-prem.
We forked the code base.
We started a U.S.
office, like the Mountain View office.
So we did a number of things.
If I could whisper, I would say move faster.
Because those, at the end of the day, turned out to be right.
And we debated a lot in terms of whether to move and also to start some centers and everything.
It felt eternity during that time.
I would say, move faster.
Less talk, more do.
Yeah, more do.
Good, good.
And then one very, very final ask.
Basically, one advice that you would give every CTO out there to build instead of buying.
Like, which tool should everyone...
build themselves instead of buying something?
Like what would you advise everyone out there?
Yeah, so my general take is for literally every CTO, CIO, and even like anybody who can, they should absolutely try to build something themselves with any AI.
It doesn't matter what you use.
You can use Cloud, Codex, pick your favorite, Replit.
Pick anything, any wipe coding platform that you have, anything that you can get hold of, just play around with it.
Because...
as soon as you start playing with it, you might have done ChatGPT.
That's different from actually building an application, building an agent, deploying an agent, and just going through the life cycle of how it was because you might have done it 10 years ago, 20 years ago, but doing it now, it's so much fun.
I'm telling you, this has been the best year in terms of you can build, you can see it come into Fusion much faster.
It's just a lot of fun.
Play around with it more as a game and a fun than seriously, oh, I need to write some code today because it's not the case right now.
Yeah, this is actually like my most favorite thing to ask when hiring someone.
Like, what did you build last week?
Like, what system do you own?
What really survived?
Maybe in your private life, like how many hobby projects do you have?
Did you ever try to buy a Raspberry Pi and hand it over to Claude and say, hey, go?
I have all versions of Raspberry Pi sitting here.
I have a bunch of other systems and whatever else, NVIDIA chips lying around.
But I also, in the last week, I played around with Jev and compared with...
Jev is this new model that came out that does...
decision making much faster.
System one thinking is what the system is, what they call it.
It was so much fun.
Just to figure out, I guess, where it can fit in the system and what can it do, right?
Like how, yeah, how can it fit in, right?
What's the actual goal of it?
We are doing it is really good in verification piece.
And we are trying to figure out, I guess, what points do we insert where it can make those decisions much faster so that we can do a lot more in the timeframe that we run the system.
And it's also much cheaper.
And we have also built our own version of Java.
Anyway, we are experimenting with it.
But in the weekend, as soon as it came in, I spent the whole weekend.
doing a number of experiments with it.
Very cool, very cool.
Yeah, you have a supportive family, obviously.
Totally, and it's, my son is working and he's in AI, so we geek out a lot.
Okay, yeah, very good.
My daughter is doing robotics and my wife is fully supportive.
Otherwise, I could never have done this.
So, Sri, thanks a lot for the podcast.
It was really, really entertaining and all the best for your future.
And let's see where, whenever your tool becomes PLG and everyone here can try it out.
Where can people find you and Sycamore?
People can send me an email at shri at sycamore.so or sales at sycamore.so.
Sales at...
Or on LinkedIn, I guess.
So thanks a lot for the podcast.
LinkedIn for sure.
All right.
Have a great day.
Bye-bye.
Hope to see you soon.
Bye.
Thank you for listening to the Alphalist podcast.
If you liked this episode, share it with friends.
I'm sure they love it too.
Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available.
Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company.
Please send us suggestions to cto at alphalist.com.
Send me a message on LinkedIn or Twitter.
After all, the more knowledge we bring to CTOs, the more growth we see in tech.
Or, as we say on Alphalist, accumulated knowledge to accelerate growth.
See you in the next episode.