# The Agentic Architect: Build Trust, Not Just Code - Workday DevTalk

## Метаданные

- **Канал:** Workday
- **YouTube:** https://www.youtube.com/watch?v=sGhCAXDXpZ4
- **Дата:** 13.05.2026
- **Длительность:** 35:57
- **Просмотры:** 40

## Описание

In this episode of DevTalk, host Nick Moores and Kathy Pham, Harvard Fellow in Responsible AI, dive deep into the world of AI agents and the developer ecosystem. They discuss why the shift to AI agents necessitates a new system of record, why governance, trust, and auditability are the "whole game," and why open source is in its moment now.

Listen to this episode on:
Apple Podcasts: https://podcasts.apple.com/us/podcast/workday-devtalk/id1846666598?i=1000767585819
Spotify: https://open.spotify.com/episode/7J8SrsrPxX4TdlbHeJddhd?si=Lb1foGAdT5GMpehv2-xXhA

## Содержание

### [0:00](https://www.youtube.com/watch?v=sGhCAXDXpZ4) Segment 1 (00:00 - 05:00)

Hello, I'm Nick Moors, host of the DevTalk Podcast. Today we are unpacking why the shift to AI agents necessitates a new agent system of record and how this is redefining the developer's career path from coder to orchestrator. Joining me for this conversation is Kathy Fam, Harvard fellow in responsible AI. We're going to discuss how open source is empowering developers to influence the projects that power our ecosystem and why your wisdom premium in 2027 will be measured by the trust you architect, not just the code you write. Let's jump into the conversation. Let's just dive in. So, open source at workday, like I'm a true believer on some of these things. At least I think I am. Like, tell me what does that mean? What does that mean for workday to be embracing open source? — Yeah. The open source movement has been around um for several decades now. And I'll make a plug for the conversation with Chris Dabona that I also just had where he went through the history of open source and why this move this moment we're in with AI has completely changed everything but also in a really good way of the access that people now have to tooling and how we have to come together to build the foundation for what comes next. So for me that's what open source looks like. It's the place where we can put aside our affiliations. I mean it's actually a mantra I often follow which is use your affiliations to come into a room because sometimes it's helpful to know the background we have the depth of experience the lived experiences our skills and then once we're in the room you leave that at the door the hierarchies the backgrounds because we're all there to build something together so if you think about things like the Linux kernel um which was like an alternative version to an operating system or you think about like Python and um the developer ecosystem around that like it's a coding language that many people can contribute to. And now you think about things like MCP which is a protocol for agents to connect to each other. Lots of companies have come together to build and contribute. And these things can only happen when we all set aside or actually we bring our expertise to the table but then we put that aside for a minute with the whole purpose of building better languages, building better foundations, building ed better frameworks for evaluation. So, it's not just code, it's frameworks around how we evaluate systems, right? One of my favorite examples is Netflix Chaos Monkey, where it's not their core code, but they're like, "Cool, cool. We've discovered how to introduce chaos, if you will, into your system so that they can be more resilient. We'll share it with you, too. " So, that's what excites me about this moment we're in where just the whole concept of being a developer is changing. It's this space where we can unpack what it means to be a developer together, to try new things together, to learn from each other, um, and bring our experiences, but then only merely use that to decide, um, like how we come together, but not what we produce. And it's a really exciting time for both open source and AI and just the future of like what development means. — Yeah. No, I couldn't agree more. And frankly, like at the same time, we're working on opening up our developer platform, program. I could have borrowed all the things you just said and say why it's such a big deal that you invite developers that are not in our little our cute little work bubble and come with fresh perspectives, global perspectives, perspectives from other ecosystems, other tool sets and stacks. Uh, and when you bring them together to solve really big juicy problems, good things happen. So, I'm so thankful that these things are kind of happening at the same time. — You've been leading that for years now, building out that developer ecosystem with this foundation of trust and responsibility. When folks throw out, you know, ethics and responsibility, it's not just about like the philosophy, ethics. It's about how we responsibly build infrastructure and architecture and bring people together. Um, can you share more about what that's been like? — You know, frankly, like I think that there's a highbrow answer and there's a dead simple answer. The dead simple answer is that if developers don't trust you, if they don't trust the tools, ecosystem, none of it matters, frankly. Like, um, our good friend Cassie Stewart likes to say that think of developers as your most skeptical friend. And I actually really love that visual because you really kind of got to prove it to them. You got to win them over that this is worth their time, that they're not going to be ripped off, that you're making their lives better. And it's not I don't think it's fully like a selfish thing. I think it's like a healthy skepticism thing and a deep

### [5:00](https://www.youtube.com/watch?v=sGhCAXDXpZ4&t=300s) Segment 2 (05:00 - 10:00)

curiosity because when you win them over, they become your fiercest champions. But they need to know that what you're what they're building and what we're working on together is worth it, that they can trust it. So when we're rolling out new tools, like especially in the workday space, you can't just build stuff and have it kind of work. Like the enterprise guard rails are there for a reason. Like you can't get the people and money data wrong. H and people are building their career here, which is amazing. But so I think I'd think of it as the trust, but to the nth degree. — Yeah. And the extension of that for me that's really exciting is to your point when you're building enterprise software where there's guard rails that's really critical clients across let's like healthcare government places that's like meaty and critical and you're like I'm not going to mess with the guardrails. — Yeah. the sheer process of creating the process for figuring out what kinds of guardrails, what kinds of evaluations, what kinds of frameworks, what kind of infrastructure to operate in that environment is in and in itself really valuable for the developer community, you know. So I think like that's like the scaffolding around the code that is just as important to release out and share and then iterate on of like better ways to build that foundation so that you can build on top of it. Um, so that part really excites me as well with all the open source efforts. — Yeah, absolutely. And I think that when you viewed all these things holistically, it makes sense why Workday came out of the gate first with like the agent system of record AI wise. Like I'm not going to lie, like I kind of moonlight as product marketing. I'm like cool, a system of record. Like meanwhile, the rest of the world is building like AIs to do this, that, and the other. But over the past few months, it's like slowly percolated into my brain that actually the governance is the whole game. The trust auditability is the whole thing. So making sure you have a one-stop shop for centralized governance, for AI, for agentic tools uh is simply critical. So Kathy, you before we started recording, uh you disputed that the build fast and break things era is over. Can tell me why. — And so I think there was a period where we challenged the mantra of build fast break things. realize what happens when you break things especially critical infrastructure and we move in the direction of um build responsibly or actually a thing that um DJ Patel who is part of um the White House office of science technology and policy while I was also there with the US digital service talks about is how do we move purposefully and fix things and I do think there was a phase that was that — um which I also I'm surprised to those who know my background like subscribe to right like we can move fast but also purposefully and fix things and come up with net new things. I also think move fast and break things has a comeback. Um and how both because of the landscape of how quickly it is to move fast, right? You can spin up a company with multiple agents and a whole framework and be profitable sometimes within 24 48 hours. Um or you can develop prototypes. you can come up with something that looks almost there. And so it also gives the impression that you can build a whole system. And in some cases, you can, but in other cases when you move really fast, there may be small nuances on why someone did something, especially an enterprise system. Maybe it's because in certain parts of the world, servers go down because of like weird weather patterns that just aren't totally in models yet. or maybe because it's just like a weird quirk in like the workforce in that region where someone literally turns on a server every night or like there's just like these weird quirks sometimes um and when you move fast especially an enterprise system and that's different than like a consumer system you ultimately could break things and I think the ability to move so quickly has brought back the move fast and break things um and cons and I say the reason consumer is different um is there's a lot of risk there too but often times sometimes those risks are not as high as like the irreversible damage if you have in like a healthcare government system for example. And so maybe another framing is like if you are to move fast and break things because it's just so easy to do one you should evaluate that. But let's say that's like the only thing you like you're like you know what I'm just gonna keep moving fast — then maybe also learn how to fix things very quickly as well. — Um as that as like a compliment and — I don't know the ability to like understand what to fix is also now there you know like how to understand your bugs how to understand why a system failed. we have more information than ever, but there's also the bucket of like we're always chasing understanding failures, right? Because we just never know net new problems that could arise.

### [10:00](https://www.youtube.com/watch?v=sGhCAXDXpZ4&t=600s) Segment 3 (10:00 - 15:00)

Um, so maybe that's my call to action like if you're going to move fast and break things, which you should move purpose purposefully and fix things. Um, then also learn how to fix things quickly. — Yeah, I think that's so important. Um, the ability to have like self-healing or recoverable systems. One of our good friends, Matt Kandolivitz, one of his first like agents out of the gate was an integration agent. And if any of you uh were trained like me in the science and art of workday integrations, some of our customers have like hundreds if not more of systemtosystem connections. And for all the reasons you mentioned, either us or a third party, you know, you're delivering a file somewhere, any number of things could go wrong with the server that's catching that or sending us something. Uh so we have a huge opportunity now to say like how can we scan across that landscape, recognize that it's probably one of these 10 things that may have gone wrong and be able to recover quickly, be able to fix quickly. That was just an example that came to mind that I'm really excited about. — That's a great example and that's a whole discipline and field too, right? Like you have site reliability engineers, you have DevOps and these are roles where it's like you've honed the art of fixing and keeping things resilient. So let's elevate that or continue to elevate it to be just as important. Especially now, like if you're going to build an agent system, have your agents also build your Devril and your DevOps agents at the same time as you're building all your other agents to help figure out how to fix anything that might be broken. So, that's how I view the current resurgence of the buildax um and break things. But also would love to hear how you think about it. And you mentioned this briefly, but also how you think about this is like the Nick wisdom. How do you think about the skills that are really important right now um as we think about this new landscape of how we're building things? — Yeah, I'm glad you asked that. So, uh in my free time, I like building things out of wood. I like doing woodworking and I have learned so much from that. And there was even before AI like exploded onto the scene, massive debate over whether using a CNC like computer that accurately cuts everything counts as woodworking. Uh, and it keeps coming back to my mind because you could build anything in your house with just a chisel. That would be insane. But you could hand planes or just chisels in a box. A very clever box. Can't believe I'm going down this rabbit hole, but I do love it. — I love this rabbit hole. — But the whole point is that we have increasingly sophisticated ways of doing the same job. But if you don't know the problem you're solving or if you don't have an idea of taste or of architecture or of design, it's kind of meaningless. Like you can get to where you're going faster. You could also get to the wrong place faster. Uh so when I think of like what does Devril need to do as we're onboarding people into a community and in theory you know I remember when it took days to build like a solid extend app. I'm only slightly exaggerating. Um now with some of the things we're working on let's just say that quite frankly it would take minutes or less. But how do you know if you're solving the right problem? How can you spot if there is even a problem? Like you have to have a passion for the space you're in. You have to know like is the cabinet I'm building does it even fit? Did I measure it right? Like that becomes so much more critical. And going back to the CNC example, you could build a hundred of them perfectly. But if they're all wrong, like then they're all wrong. Uh another analogy I like to think of is uh I saw this on LinkedIn somewhere. I wish I could credit it is AI is kind of like a helicopter that takes you somewhere. Like you could hike up the mountain and you would get a heck of a lot of experience, grit, journey from that. The separate question of like does this actually count as like climbing the mountain if you took a helicopter? Like maybe I'll table that for the for another time. But like if the helicopter drops you off at the wrong place or if you're not dressed for it, like did it really get you where you want to go? Like you really need to know where am I going? Why am I going there? Am I prepped for it? Because if I get dropped off in the wrong place and I can't recognize it, like that's what we need to help guard you against as Devril and as leaders. — Oh man, there's so much to unpack for that. I will put a seed. And also this is just a call to myself because I have a piece that I'm almost ready to get out around — um agency, purpose and capability and so to understand what the capability of the

### [15:00](https://www.youtube.com/watch?v=sGhCAXDXpZ4&t=900s) Segment 4 (15:00 - 20:00)

tools are the agency you want to maintain and the purpose to your point is the purpose getting to the top of the mountain or the purpose like climbing the mountain because sometimes you might want to get to top a mountain. Maybe someone's stranded there and you're trying to help them. That's like a different scenario. I like Um, but if you're trying to, you know, scale a mountain to say I scaled a mountain, that's different. Uh, and so that's a great that's more on that. That's some point. And I'll also add, you made me think of something else that I love to bring up both with I teach a class. I brought this up with my students recently and also my kids. I glass many people have likely seen this, but if you haven't, has a piece about create the creative process where especially if you have taste. So Nick, for you it's like if you know what good woodworking looks like, a good table, good cabinet, but you're a beginner in it, there's a big gap and it's really frustrating when you start cuz you're just like, I know how to make this like I know what good is. I know like when it slides nice, but like you're just I can't get there. And it takes just the practice of getting there to eventually get there. And you can also buy bookcase. Sure. Um, but that process bridges you to get to that point and then you learn how to like you learn the good taste and then you like hone what taste is even like and you like oh I thought I had taste but actually like the art of building this and that's where I think having the community of like the guilds around you whether it's woodworking or developers also help you hone what the good taste is and how important it is to not skip through that process just to get to the bookcase, the bookshelf, the finished version of the code, the like the fully formed new system of a bunch of agents when it's just as important to learn the skills to get there. — Totally. — And then use all the skills to make all the things really quickly um after you've like bridged that gap, right, of um taste and beginner. — Yeah, absolutely. Um I'm reading a book called The Way of Excellence right now by Brad Stolberg and he meditates on a lot of these things. highly recommend it. He like introduced that framework from like 50 years ago, I think, of like, — hey, you don't know that you're not good. You do good, which is kind of what you're talking about, conscious incompetence. Sounds horrible, but I feel that in my bones. — And then there's like, I know I'm getting better. And then I don't even have to think about it. Like there's mastery and I'm just flow. — I conscious incompetence. I love it. It It's almost a It's not It's a freeing concept, right? Because you're like, "Oh, I'm incompetent right now. " But it's okay. I just haven't learned it yet. It's like with my kids can't figure out how to tie their shoes because they're two. I'm like, "That's okay. " Yeah, — that's like an acceptable level of incompetence. You literally have never like held a shoelace before. That's okay. If you've never learned to code before, that's okay. Like, it's okay. Like, you go and you find your people to teach you how to do it. You do it a few times and you learn. — Yeah. And you need to be the one doing it or at least you need to be thinking about it for it to actually help you get better. Um, something that one of my mentors at Stamford told me once was that you can only learn what you almost know, otherwise you're throwing crap at your brain. And it like blew me away and I still think about it all the time. We have instructional designers on my team and we think very deeply about the developer onboarding journey and it makes me think of like a ladder like are all the rungs on the ladder like you were talking about that gap that Ira Glass is talking about. It's like great, there's a ladder, but the first rung is like way the heck up there. Like, uh, it's our job, even if the tools help you get from here to here to help you know like this is the direction, here's why, here's the purpose, and there might be a gap that you need to fill. Like, so if you don't have the tool or you got to fall back to like hand tools to do this, — like totally um th those skills are what are what's going to get you through. Okay, I want to pull on that um and bring us back to given this is dev talk the software development life cycle. — Love it. Because what we know that is let's say the ladder for um a software product development life cycle is has completely like the ladder looks different right like you don't before you know you're like I write some code I do some testing like I get some reviews I do some evaluations I do some unit testing and functional testing and then I launch and then I do all these things um but that when like I have like a software developer here and a front-end developer over here you have like this structure where you climb up the ladder and you like reach out for help as you need for different roles but that ladder looks different now whether it is you have someone front end backend full stack and then the cycle around um do you even follow the same you know like ideate and then iterate and build and you know the whether it's the design

### [20:00](https://www.youtube.com/watch?v=sGhCAXDXpZ4&t=1200s) Segment 5 (20:00 - 25:00)

cycle or the product cycle they're different how do you and you're so close to developer communities day-to-day. How do you see the difference? So, two, that difference? And then how do you talk to folks about how to navigate that difference now? The ladder, if you will, has changed like climbing it the same way isn't going to and maybe you shouldn't climb it the same way, right? If you have new tools. — Yeah. I think you brought up an interesting thing earlier of like having a community that mentors you. And I was I recently was talking with folks from Salesforce and Brock AI as like a Devril council kind of meditating on this exact question of like hey if you can onboard people faster than ever like what are we doing here or like what are developers doing here and like you really need to foster like a sense of the mission that we're all sharing whether it's an open source project or workday development like you got to care about the end goal like is there a person on the mountain that we need to pick H otherwise they will build something else, you know. Um but then it really to me is about — developing that like intuition, a very strong intuition for like this is on the right track or I'm on the wrong freaking ladder. Um and that's actually not easy and I'm not yet sure that AI is a great fit for that. I really think there's something about humanto human mentorship and skill building that is somewhat hardwired into us. Um having like a role model, someone that you look up to that you're like, "Oh man, I want to be that person. " Like that's a huge reason why we have our MVP program and we have their faces on the giant ball at Rising, right? We want people to go like, "Dang, I want to be like that person. I want to talk to that person. They're answering my questions on the forum. " And I think that just like activates something in you. So the super short version is that it comes down to like — understanding the principles, caring about the principles. Like I know I'm building the right thing. I have a good understanding of like good architecture especially for like software that you're building for enterprises. Performance is a huge thing. Like are you getting the right thing but your code is like spaghetti code? Does it have 10 times too many functions? Like these things really matter if like hundreds of thousands of people I'm thinking of some of our retailers that use our apps. If hundreds of thousands of people are hitting the thing at the same time and you built the app 20 times faster but it's going to run 20 times slower like you need to be able to catch that even if it's a non-automated thing. And some of those things come down to like taste architecture experience. And I think that human-touman mentorship is where that wisdom really trickles down. — I agree with that so much. But and I also find myself I live in a state where I'm constantly arguing with myself cuz I'll see like multiple sides of many things. So I'll be like I can see scenarios where um deploying oh I just use this case of like the human mentorship and wisdom of understanding let's say can a new app that you build scale and be reliable for x number of real tailor across the globe and understand every single weird nuance of what performance and resilience really looks like ranging from how many people might use it at any point in time to like global events that might affect when something stays up or down to like even, you know, we see like the state of like natural weather patterns affect systems sometimes that people don't anticipate all of that, right? And it takes wisdom and understanding and if you have the access to the people to do that, there's like a lot of like just knowledge that isn't captured digitally that like will not make it. But then on the flip side, you have let's say developer communities for whom we've gatekept whether it's through getting a degree at a university or being inside certain companies. It's like you don't get to do this kind of development. Um and that's where having with information to some extent there's like downsides of that too where it's like oh now you can look up how to do X whereas before you didn't know. You didn't have like someone teach you for a number of reasons. Yeah. Access power whatever it is. Yeah, — LLMs do that where they're like, maybe you didn't have access to the resources to do these things. Here's how you could code up just enough version of something. Um, here's how you can learn how to scale to x number of users because you don't you've never had anyone around to teach you how to scale from like 10,000 to 10 million. — Yeah. — Um, but then if you only do that, there are likely gaps that you won't see. So for it's like that that balance um of and I'll just I'll also cite Natalie Manabot who um works on this startup that dealt with like that deals

### [25:00](https://www.youtube.com/watch?v=sGhCAXDXpZ4&t=1500s) Segment 6 (25:00 - 30:00)

with digital twins. So she's like deep in the AI space. She has a piece out recently in Fortune that talks about the correct division of labor and it's like it's not about use AI or not. It's about let's think through the right division of labor as we deploy all the technology. So going back to what we're talking about here, it's like the right division of labor to really understand how we do resilience testing and scale and like the wisdom needed there. The right division of labor where actually we don't have enough people over in this part of our company. So we might have to supplement them with like certain agents, but over here we don't need that and we have enough people just to fill these. So it's like the nuance of the right division of labor as we go through our whole software process um is really an interesting area. — Yeah. And it's changing all the time. If you if it takes fewer humans to get you from A to B like the ability to audit it, the ability to observe recover is so much more important. Um, one of our good friends, Katie Holden, uh, talks a lot about how it's not like, oh, we're able to get it 10 times faster, so we need 10 times fewer developers. It's like, no, that means every developer is going to be building 10 times more things. So, like that's a huge volume increase. I think about that a lot too is that really like — you we're going to get that many more poll requests and like that much more need for like how do you responsibly audit all of those things. So I would love to spend a bit of time talking about the OSPO. Um so there's a version of our agentic future where everybody's AI stack, every enterprises AI stack is a proprietary black box, but it's our black box, right? So everyone has different audit trails, different governance, different interoperability. The OPO in my understanding exists partly to counteract that. So, how are open standards specifically helping us define how enterprises should do that? — I'll have to look up the exact number. So, this is me saying my number is I'm throwing out a number that is greater than 50, but I don't know the exact like maybe 60 80, but it's like a higher number that's higher than 50 that the number of the percentage of software that is used in the proprietary space and enterprise spaces behind walls is run by open source. Right? You can think about it as like think about the big ones that come to mind for at least for enterprise like Kubernetes, Kafka, Polar like these are things that are vastly available that over time big companies have used internally to build the infrastructure of their organization. So this moment is no different. I love to think of like how historical context informs what we do now. This moment is different and also not. Um so we're moving quickly to build agentic system AI systems but also very quickly at the end of 2024 um yeah 2024 early 2025 organizations um with uh quickly realized we needed like a Google put out A2A um Anthropic put out MCP I think IBM has ACP I forgot what ACP stands for um and they're like cool we're all big proprietary system moving fast with AI we got to build some open protocol calls to connect to each other. — Yeah. — Uh — like it's a practical matter at the end of the day. — Totally. It's a practical matter. It's like the analogy I think about often is we can all build cars, the best fancy cars. What happens when there are no roads to drive them anywhere and the best way to build those roads? Sure, you have an entity that builds like kind of owns the roads in some cases governments, in other cases private ownership. But the standards for what the roads look like, how they're built, the kind of material, like these are things that need a lot of collaboration. — Yeah, standards. Standards is like correct screaming at me. So, — we see this case with like security standards that have existed over time, frameworks. So if anything, the fact that we're all moving quickly to build software, it's just let's lean on the same frameworks we've had of we need each other to build the standards and scaffolding and we also need each other to Anthropic just put out um like just actually I think of it as a movement uh for the world to look at what they put out to find security flaws and build on that together. It's another way for the world to be like, hey, — those preview or a different one. — I'm sorry. — Like Project Glass Wing thinking of Yeah, — Project Glass Wing. Um, — and let's look at ways where we can get a bunch of folks together, give them either a preview or access, and then have them help us build better. Yeah. — Right. This is an age old at least for as long as software and open source has existed. To summarize, it's a way to build common standards and

### [30:00](https://www.youtube.com/watch?v=sGhCAXDXpZ4&t=1800s) Segment 7 (30:00 - 35:00)

infrastructure together, which we need. um a way to get your software and code out there so that the whole world can help you make it better and help you maintain it. Um and also if you look outside of that, it's like um how do we also continue to release ways to like test and evaluate these new systems that are constantly changing so quickly. It's like we have to share ways we test and evaluate. Yeah. Um because that's the only way collectively we'll be like, "Hey Nick, I found like this is a weird bug I found. This is how I got through it. Cool. " Like I'll share with you and we'll just put it out on GitHub or on a blog or whatever, wherever we decide to put it. Um — to help each other out. — Yeah. We need a common language. Um otherwise it's confusion. It's complexity. Uh it's like everyone uses the same standards for like hardware for screws. Like it'd be insane if we all had different ways of doing that and before we had mass production like we kind of were. It's wild to think about. So — yeah. And there are some cases you might want like fancy different screws, right? For sure. And for like reason where like it's creative and fun like a little screw that goes into a little dinosaur bot for like a four-year-old to screw on. That's probably a different standard. Um but when you have bridges globally where that affect millions of lives and you might have different architects and engineers that come in to work on them, you definitely want a set of standards. And I see that now with I mean it's not new. It's like it's a continuation of just new standards that we have to build. — Yeah. — Um for this new agentic AI language world model phase that we're in. — Absolutely. So workday DevCon in June 2026. Lots of exciting things, things that I will try not to talk about, but suffice it to say there will be even better, more awesome ways to build all the things. And yet we think it's really freaking important to get all of you in the same space building together. What do you think they should take away? Like be most excited about? — One, bring ideas you have. Um, and I know that sounds obvious, but sometimes I'll hear folks like, I'm just kind of building this thing. I don't know if it's good enough to share. I don't know. Do it. like everyone I have I've heard enough opinions from people worried about their thing not being cool or good enough to be like no you're not the only one. This is the space to go and like I've been tinkering with this. It's kind of weird and I'm like no that's awesome and it's like the place where people be like that is so cool. Thanks for teaching me something new. Um so bring your ideas and what you're playing around with agents. Maybe you've connected them. Maybe they're independent. Maybe you found some like interesting guard rails to build. Bring all of that. Especially because at DevCon folks come from really different industries and backgrounds. So someone in healthcare is hanging out with someone in retail is hang higher ed and you're like oh my gosh all of us are kind of the same but also really different and coming together we can find really cool new things and also like bring your thing but also um come and like learn, right? So, not just like I have so much to share, but be curious and be like, "Oh, show me what you have. Tell me about you. " Like, not just your products and tools, but like what kinds of problems do you have in your large retail organization? complicated higher ed thing, you know? Um, — yeah. — Be curious and come so share and be curious. — Love it. and between developer meetups where we're trying explicitly to get folks to we're fostering spaces for folks to do that to the hackathon where we usually have customers from different customers all joining together working together on a thing. They haven't met each other before and we've had customers win because of those intersections and those sparks that they give each other to our new learner track where you don't have to have hacked before like people sometimes think like oh it's this big intimidating thing. It's like, no, come hang out, build agents with us, and learn together. It's going to be really, really great. Kathy, I think this is probably a great time to wrap. One more piece of advice for our developers before we go. — This is I've been building software for now over 20 years, and you know, you've been hearing this a lot, but it really is an exciting time. And I think what makes this year different is that we're really seeing products and tooling that comes out that connect systems together and chains them together and produces multiple agents, but in like a way that's pretty easy easier to do and more accessible, not just like you had to jump through all these hoops to do. And so pay attention to that. try and play and not just think about the individual things you can do on like a one-off, but think about like a systems level thinking of what you can chain together

### [35:00](https://www.youtube.com/watch?v=sGhCAXDXpZ4&t=2100s) Segment 8 (35:00 - 35:00)

across multiple domains and areas because I think this is the year we're seeing folks be able to like connect things in like a systems level, like a systems engineering level. And like if you went to like CS computer science programs like I did, we don't always get deep into systems level, but it's like the architect systems level that is really exciting for this year for me. So everyone is an can be an architect to bridge and connect systems together. — Yeah, we kind of have to be. Well, Kathy, thank you. And for everybody at home, we hope to see you at DevCon on the ground in person or digitally. It's going to be fabulous. Those interpersonal connections are more important than ever. Don't forget to subscribe to the Workday Podcast Network and we'll see you again soon.

---
*Источник: https://ekstraktznaniy.ru/video/50594*