YT YouTube2Text

YouTube2Text → Transcripts → Fost India 2026 - Restoring Trust in AI-Native Development | apidays India 2026.

Fost India 2026 - Restoring Trust in AI-Native Development | apidays India 2026. — Transcript

by apidays · 6,940 words · 998 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:07Good morning everyone.
0:09Hope you had a good conferencing day
0:13yesterday which is probably why you're
0:15here on time today. Uh but we'll get
0:18started. I think there's been a lot of
0:21discussion around uh we want to make the
0:24agents autonomous and I always joke that
0:27we've not got humans autonomous. We're
0:29trying to get agents autonomous. So
0:31that's a bit of a stretch. But I think
0:34there's been a lot of uh interesting
0:36work that's been happening in the last
0:38uh at least two years to move towards
0:40this direction. And I'm going to share
0:43some of my uh experience having worked
0:46with lots of enterprises in terms of how
0:49we are approaching this. I don't think
0:51we have an answer uh but we have a
0:53direction and that's kind of what I'm
0:55going to try and present here. Um but
0:59the first question to ask is why do we
1:01want the agents to be autonomous?
1:04What is that we are trying to achieve?
1:08Right? My hypothesis is that every
1:11organization wants to optimize the idea
1:14to cash cycle, right? And agents are a
1:18great way to accelerate that to get
1:20faster. And so that is one of the
1:23motivations at least is to optimize this
1:25to reduce the time to market to be more
1:28responsive etc etc. And this is not new.
1:31I mean as as a industry as software uh
1:35we've been doing this for many many
1:37years and there have been two kind of uh
1:41big ideas that uh we have been uh
1:43putting to use uh for many years in
1:46terms of optimizing the concept to cache
1:49uh cycle. One is modular production
1:53which is basically defining components,
1:55defining modules, having a clean
1:57interface between them and allowing them
2:00to be built parallelly so you can
2:01assemble rapidly and get it out. Right?
2:04So this is one way of uh basically
2:08reducing the time to market right and
2:11the other is uh just in time which is
2:13again very important from minimizing
2:16inventory and optimizing flow. Um so
2:20these two two two ideas have been around
2:22with us for many many years and we've
2:24been trying to do this and since this is
2:26API days conference I'm going to try and
2:29uh map this to what does this mean uh
2:32you know to APIs right so if you think
2:36of modular right I believe uh we've kind
2:39of now established that you know APIs
2:42are kind of the Lego blocks right the
2:44building blocks by which we can assemble
2:47integrate and build products rapidly,
2:50right? So we can reuse, we can uh you
2:53know basically bring things very rapidly
2:55together and go from concept to idea in
2:58a very short cycle. U
3:01however
3:03we've had several challenges along the
3:05way, right? And one of the challenges to
3:09really talk about is what's happened in
3:11the last I would say 15 years at least
3:14in the you know the desire to move from
3:16monoliths to microservices expose
3:19everything as interfaces actually it's
3:21interesting to see uh who would you give
3:25credit to in terms of uh coming up with
3:28this idea any thoughts
3:36Uncle Bob.
3:37>> Uncle Bob. No, no, no, no.
3:44>> Who actually made the case? Uh, I mean,
3:47of course, this is debatable. Uh, so I'm
3:49going to present my viewpoint, but I
3:51would say the credit should go to Jeff
3:53Bezos
3:55for really pushing with the API mandate.
3:58uh he wrote a letter uh you know across
4:01Amazon to all the development team all
4:03the engineering team saying going
4:05forward everything should be built so
4:08that it can be uh exposed as a standard
4:12interface and integrated uh it doesn't
4:14matter if you're building internal stuff
4:15or external stuff everything should have
4:18a clear service boundary and your
4:20implementation can be in whatever
4:21language you care I don't care but it
4:24should essentially be remote procedure
4:28invocation with a clear service
4:29interface, right? And so,
4:32of course, there are a lot of other
4:34folks who've also had this idea. And so,
4:37uh, we've gone through this, but one of
4:39the big challenges you will see when you
4:41move from a monolith to microser is you
4:44lose the compiler safety, right?
4:48Anyone's had this challenge?
4:52When you had a monolith, you had like a
4:54lot of feedback you could get. If you
4:56made a function call, you missed a
4:58mandatory parameter. You know, it would
5:01be a compile time error. When you do
5:03this across a network boundary, it's not
5:06easy to get this feedback. And where
5:08this becomes interesting is when you
5:10deploy agents at scale, uh the problem
5:13gets amplified, right? So the problems
5:16of things like you know not having the
5:19compiler safety now becomes a runtime
5:21issue and this is where the problems
5:24kind of start amplifying. So what do we
5:27do to to kind of uh deal with this
5:29problem? Right? Before we kind of jump
5:32into the solution, let's kind of quickly
5:34take a quick analogy to just put things
5:36into perspective. Right? Uh so anyone's
5:40been at a really good highway where you
5:43eventually end up with a single booth or
5:45a few booths and you have to pay toll
5:47before you can move and you see a
5:50massive congestion, right? So you're
5:53building these massive
5:55parallel highways so that people can you
5:58know go really fast but then you
6:00introduce these artificial uh
6:03constraints which really bottleneck
6:06people right and so uh you can draw
6:09analogy to software right everyone can
6:13draw an uh can can apply this back to
6:15your teams and software
6:23like a lot of companies I I still think
6:26have these central teams uh which are
6:28kind of the toll boots uh and they
6:31essentially block uh the path to
6:33production. Uh I'm not saying that's a
6:35bad thing. What I'm saying is
6:37essentially this becomes a bottleneck in
6:39the system. And so I think over the last
6:4220 years maybe because of agile devops
6:45and a lot of things that have happened
6:47uh people have moved to what we call a
6:49streamalign teams uh where they are
6:51self-contained teams they have all the
6:53cross functional capabilities and so if
6:56you kind of apply that to this analogy
6:59essentially what you're doing is you're
7:01basically introducing a toll booth per
7:03lane
7:05yeah
7:07and I would say this is much better than
7:09what we had before but this is not what
7:12will get us to that concept to cache in
7:15few days uh kind of a thought process
7:18that we have right so if you really want
7:21to move to that what you need to do is
7:23you need to make sure that the vehicles
7:26don't stop
7:28the flow does not get impacted right so
7:32if you if you do things which allow
7:35things to move seamlessly so in case of
7:37like a lot of countries have implement
7:39mented this where you don't have to stop
7:41at a toll booth you just keep driving
7:44right and you use RFIDs and other kinds
7:46of things which automatically you know
7:48charge right so uh what is the
7:50equivalent of that in software that we
7:53are trying to do
7:59>> uh autonomous agents feel like the
8:01second one to me
8:05at least as of today because in a lot of
8:08companies you are deploying autonomous
8:10agents. The agents are producing things
8:13at a very rapid pace and then you have
8:16someone who has to review that. That's a
8:18toll booth.
8:26>> So some people say okay we're going to
8:27in add more agents who are going to
8:30automate the toll boots, right? Uh but
8:33then I've not at least met any large
8:36enterprise that can completely trust uh
8:39nonhuman
8:41uh you know toll boots if you will uh to
8:44let things just go to production. Some
8:46have tried and then they have regretted
8:49uh we've seen all those stories. uh so I
8:51don't think we are yet at the stage
8:53where you can say that we have
8:55completely achieved a a flow in your
8:58software delivery which has basically no
9:01uh stopping no toll boots right it's
9:03just seamlessly flowing
9:06so
9:10let's quickly move forward uh so we are
9:13not the first to actually have this
9:16problem so I'll again draw another
9:18analogy from uh textile. Anyone's
9:22familiar with uh looms, right? If you
9:25live in Bangalore, probably you should
9:27be familiar with looms because this used
9:29to be a pretty massive uh silk
9:32manufacturing hub. Uh those places got
9:35taken over by software factories and you
9:37know you see the history repeats itself
9:39in some sense. So uh back in the days
9:42you would have uh hand looms where a
9:45craftsman would sit and basically handw
9:47weave cloth uh and produce really
9:50beautiful design but it was a very much
9:52a craftsman uh ship approach to building
9:55cloth right
9:58of course this had limited uh errors and
10:02it was kind of uh well controlled uh but
10:05you know you couldn't like really
10:06massroduce so during the second world
10:08war or even probably the first world
10:10about people wanted to mass-roduce cloth
10:13and this was not a solution.
10:15So we had the next wave which is the uh
10:20power looms right uh which basically
10:23meant that you could uh now mass-roduce
10:25cloth but unfortunately when power looms
10:28were originally introduced you would see
10:30something like this at every loom one
10:32person standing and watching the loom.
10:36Yeah. And so if you had a factory of 30
10:39looms, you would have like 30 people
10:41standing and watching the loom. To me,
10:43this is very similar to what we have
10:45today in software, right? We've hit the
10:47power loop moment with uh agents, but we
10:51don't fully trust the agents. And so we
10:54basically put one human at every and we
10:58call it human in the loop. Uh which is
11:00kind of uh very nice. Uh but you know
11:03essentially you're putting uh a human to
11:06kind of monitor this right but of course
11:09if you fast forward today uh you
11:12wouldn't see in any factory stuff like
11:14this. So what did what did the textile
11:17factory do to basically change this
11:19scenario
11:21right? So we could draw some inspiration
11:23from that and that's kind of the crux of
11:24my talk is basically what are the things
11:27we can draw and one company that
11:28particularly pioneered this is a company
11:31called Toyota. It's a precursor to
11:33Toyota. And what they ended up building
11:36is they ended up building these
11:38autonomous looms uh which essentially
11:42had all kinds of sensors built into the
11:45loom and that's generally now referred
11:47to as building quality in. So the loom
11:50would basically be self it's an
11:53autonomous loom. it'll run on its own
11:55and if something goes wrong it'll
11:57basically stop and ask a human to come
12:00and basically fix things right uh in
12:03fact they kind of evolved further uh I
12:06believe they have about 118 patents if
12:08I'm not wrong on just one loom and all
12:10the kinds of interesting things they
12:12have done to basically make the loom as
12:14autonomous as possible so today in most
12:17places you would go you would see a
12:19factory with 100 looms managed by one
12:21human
12:23Right. And that's to me kind of the
12:26aspiration or where you know I would
12:29personally like uh our industry to go
12:32right where you don't need uh 100 humans
12:36sitting in front of a uh agent and be
12:39becoming the toll boot to the agent
12:41right so how do we get there is is kind
12:44of the question and there are some
12:46principles we will talk about that
12:47actually help them achieve that. Uh but
12:50before that I thought it'll be
12:51interesting for those who have not been
12:52to a power loom to see a quick uh video
12:56on this thing. Okay,
13:02that's how a power loom works. You don't
13:04see a human there. And this is uh just
13:08showing you when a thread breaks because
13:10that's one of the main challenge in in a
13:12power loom is the thread snaps. uh and
13:15so they built in these kinds of systems
13:17which basically as soon as the thread
13:19breaks the liver goes and jams the
13:21machine. So it kind of stops uh the
13:24machine from continuing with an error.
13:27Right? So these are checks built into
13:30the machine not inspection not some
13:34human watching over this. Right? And so
13:36this is kind of the uh one of the
13:38innovations that uh that they did. And
13:41so this is referred to as if you look at
13:43the principle it's referred to as jidoka
13:46uh this is a Japanese term uh for
13:49basically what what the term means is
13:51automation with human touch because it's
13:54a little politically incorrect to say uh
13:57automation without human touch right u
14:01but technically uh you would see that
14:03philosophy has uh you know in everyday
14:07life things that we use so if you've
14:09ever used a washing machine and let's
14:11say the washing machine halfway through
14:13the wash cycle water stops
14:16there are sensors built into the machine
14:18that will not like just continue to wash
14:20your clothes and say oh even though
14:22water I will just wash it and give it to
14:24you right there are sensors built into
14:26it it'll stop uh another example that's
14:29very popular is in the elevators right
14:32when the door is closing there are
14:34sensors in the door if you try to if
14:36some someone is in between then the the
14:38doors will unlock right it don't
14:40continue to go through. So these are all
14:42kind of mechanisms which basically makes
14:44them autonomous right which which
14:47basically helps them achieve this. What
14:49is the equivalent of this uh in APIs?
14:59So I would say something like having a
15:02pre-commit hook, right? Before you push
15:05any change, you want to basically run a
15:08battery of tests, right? What whatever
15:10it could be linting, it could be uh
15:12contract tests, it could be backward
15:14compatibility checks, etc. And if if any
15:17of those checks fail, you want to
15:19basically stop uh the commit going out.
15:23Right? So that's kind of my example of
15:27uh how we've tried to apply this is
15:29before agents, right? This is how we've
15:31tried to take some inspiration from this
15:33principle and apply this uh in uh in our
15:36work.
15:38The next principle I want to talk about
15:39is poo yoke. Uh poker yoke is
15:43essentially mistake proofing. Uh and
15:46again we've seen a lot of examples of
15:48this. Anyone remember uh USB 2 or USBA?
15:53Uh you have to always figure out which
15:55direction because it doesn't like you
15:57can't just put it in any direction. And
15:58so when you move to USBC, uh you don't
16:02care anymore, right? You can put it,
16:03it's just you don't have to worry about
16:06the side or the direction. So it's one
16:08way of mistake proofing so people don't
16:10try to jam something. Sockets are
16:12another example. Uh so are uh you know
16:15SD cards or your SIM cards, all of them
16:17kind of have a similar uh philosophy
16:20where you design something that it is
16:22not possible for you to make a mistake,
16:25right? So it's mistake proofing. So what
16:27is an example of mistake proofing in
16:30APIs?
16:38>> Contract testing seems a little bit as a
16:41uh the previous example to me not
16:43necessarily a mistake proofing but more
16:46of a sensor that kind of tells you
16:49something's wrong. Right?
16:53So if you take this example where you
16:55say okay I have uh you know I can post
16:57an order and uh status is a is a string
17:01uh and I've written a beautiful comment
17:03that it should be one of these three
17:05things right uh but this doesn't stop
17:08someone from sending a status which is
17:11not one of those three things
17:14then you'd have to put a sensor to stop
17:17someone from doing that right but if you
17:19were to mistake proof this so that it's
17:21not possible at all. Then you would
17:23essentially define an enum and say it
17:26has to be one of these three values.
17:30Right? So that's kind of I would say an
17:32example of mistake proofing in in the
17:35context of APIs. Right? And quickly I
17:39want to touch upon the third principle
17:41which is very important because these
17:43have a dizzy chain effect and they kind
17:44of work with each other is andon. and uh
17:48the idea with andon is essentially if
17:50something goes wrong make it visible as
17:52quickly as possible so an action can be
17:55taken a corrective action can be taken
17:57an example is you you see this every day
18:00in your uh cars for example if your tire
18:02pressure is low the car can sense that
18:05and put it on the dashboard so you know
18:07about it and you don't drive halfway
18:10through and then have a flat tire right
18:13uh so these are kind of giving you
18:14feedback so that you can avoid
18:17uh you know problems later. Uh same
18:21concept uh with you know your fire
18:25sensors. uh all of these are again kind
18:28of idea to kind of give you the feedback
18:30so that you can uh you know you know now
18:33quickly moving to and in case of API
18:37what would be the example running things
18:40in CI and when they fail you get a very
18:42visual feedback saying hey you know
18:44something's wrong uh and then that kind
18:47of stops uh bad things it notifies
18:50people and so whoever pushed this commit
18:52can actually uh address this right uh so
18:56So just to quickly summarize then
18:57putting all three principles together uh
19:00the way I kind of look at it is uh you
19:03know pok is essentially mistake
19:05proofing. uh in spite of mistake
19:08proofing you may still end up with some
19:10challenges and this is where you would
19:12use DTO to kind of uh sense and stop
19:15things from going bad and then when
19:17things do slip through and show up then
19:21typically during integration or in your
19:23CI you would essentially make it visible
19:25and then any learnings that come back
19:27from it circles back and you mistake
19:30proof it right and so this is kind of a
19:32principle that we've been applying uh
19:34for a long time I would say at least at
19:36least extreme programming made some of
19:38these things uh quite popular right so
19:41uh I've given some examples in software
19:44that kind of translate to that but how
19:48does this relate to agents
19:52what can we do with these principles to
19:54make agents autonomous
20:02you already probably seen a lot of uh
20:04this kind of stuff where We're moving
20:06from VIP coding to things like
20:09specdriven development and we're trying
20:11to say okay you know if you provide a
20:13spec uh the agents will probably do a
20:16much better job than just giving them
20:18some prompts right uh and in some sense
20:22there are bunch of uh principles baked
20:25into this idea and uh if you were to
20:28kind of doubleclick on it essentially
20:31what we are saying in this new uh
20:33specdriven development paradigm
20:36Spec is the new source code,
20:40right? Spec is the new source code
20:42because that's the level of abstraction
20:44at which humans will operate and
20:47whatever code is generated as equivalent
20:49to assembly or bite code. So you don't
20:51really care about it. Uh every time you
20:53just recompile, you throw away and you
20:55start from scratch, right? uh not
20:58everyone's fully onboarded with this
21:00idea but that's kind of where uh you
21:02know like if you see the industry is
21:04going is moving towards specifications
21:07being source of truth. One other
21:10interesting idea is uh harness
21:12engineering and uh recently I think
21:14there was a interesting blog on Martin's
21:17uh Martin Fowler's site where uh they
21:20tried to kind of classify this into a
21:22little bit more uh categories. So you
21:25have guides which basically give
21:27feedback to the agent so that the first
21:31uh generation of code that the agent
21:33would do is guided based on certain
21:36things right so we've all written
21:38agents.mmd file we've written a bunch of
21:40we provide a bunch of skills uh which
21:43essentially you know act and then again
21:45uh you know you can have both uh
21:48inference-based things so any MD file
21:50and things like that you're writing is
21:52more inference based so the agent will
21:54have to infer it, derive what you're
21:56trying to say and then uh guide itself.
21:59And there are also some computational
22:01things which are not necessarily just
22:03inference based but they are something
22:05that the agent can execute as a way to
22:07get feedback and move forward. Right? So
22:10you've got the initial generation done
22:12which typically we call as the forward
22:14loop. Uh but that is not sufficient.
22:17Right? Once the agent has produced
22:19something, you do want to then use a set
22:22of sensors. And this is kind of your
22:24judokco in action, if you will, uh where
22:26you're essentially providing feedback to
22:29the agent saying, "Oh, you you produce
22:31this, but you kind of dropped, let's
22:33say, the code coverage or you didn't
22:35write tests or you you made this
22:38architectural mistake, right?" So, you
22:40kind of provide that feedback. So it
22:42goes into a self-correcting loop uh and
22:44and provides you the response finally
22:48right and again while all of this is
22:50happening human is still in the loop in
22:52some sense uh because the human is kind
22:55of watching what's happening and maybe
22:57steering not all the time sitting in
23:00front of it but maybe at some regular
23:02intervals you may want to steer that
23:04right so this is uh kind of harness
23:06engineering if you were to try and
23:08extrapolate this to like API specific
23:11specifically what are the what are the
23:14guides and sensors in case of APIs right
23:17so if I were to quickly just jump ahead
23:20uh what you will see is you know you can
23:22feed in like API best practices uh you
23:26can feed in things like API
23:27specifications you can give in examples
23:30uh you can give in agent plugins which
23:32are skills and uh MCPS packaged together
23:35uh these all can act as guides for the
23:38agent when it's producing the code it'll
23:42keep these things in mind and produce
23:44things right what are the kinds of
23:46sensors when it comes to uh APIs
23:54>> absolutely so contracts uh contract
23:56tests mock compatibility tests these are
23:59all important things like resiliency and
24:01security test becomes important llinters
24:03and other policies become important you
24:05can execute them and kind of give
24:07feedback you can look at things like API
24:10coverage
24:11uh not just code coverage but API
24:13coverage and kind of use that as a
24:15feedback again to the agents to say hey
24:17you've not covered these scenarios and
24:19things like that. So uh there's quite a
24:21lot of work happening in this space both
24:23on the guides and sensors to basically
24:25make API design lot more autonomous uh
24:28with the agents.
24:31uh but it doesn't have to stop here
24:33right this kind of can apply throughout
24:36the uh SDLC process in terms of even at
24:39further stages in the pipeline in
24:42production you can have a constantly
24:44learning running loop to basically do
24:46drift detection and so forth so that you
24:49can feed that back to the agent so they
24:50can selforrect right so it doesn't have
24:52to stop at the first uh generation of
24:55the code it can go all the way uh into
24:58your pipelines it can go all the way
25:00into production and keep the loop
25:02running, right?
25:05And I think there's a lot of promise
25:06with hardness engineering. A lot of work
25:08is happening with hardness engineering.
25:10But I would ask myself, is hardness
25:13engineering sufficient?
25:17Will that really help us achieve the v
25:20the dream of autonomous agents?
25:25And that's kind of where you start
25:27wondering about what happens to things
25:29like your architecture, overall
25:32architecture, not just an individual
25:34API, but the whole system architecture.
25:37What about things like governance? Uh,
25:39you know, would would it be able to
25:41handle all of those kinds of things? So,
25:43just kind of again like if you have
25:44guides uh that help the coding agent,
25:47you have sensors which basically are
25:49executable specifications which kind of
25:51guide the thing. So that's an important
25:53thing at a individual API level but a
25:57system is not just an individual API
25:58level right. So typically when you have
26:01some kind of an intent that you're
26:03trying to uh communicate how do you make
26:07sure that what you are thinking is being
26:11effectively communicated to an agent.
26:14Right? So there's a term that is
26:16emerging for this which is called
26:17executable intent which means that you
26:21are able to express the intent and
26:23validate the intent before you actually
26:26give it to the agent to make sure that
26:28what you're thinking is actually machine
26:31understandable agent understandable
26:33right and there are things where you can
26:35go from like plain English uh to an
26:38executable specification you can spin up
26:41a sandbox in which you can actually
26:43prototype type uh and figure out whether
26:47you know if this is your business case
26:49whether it has captured it correctly in
26:51terms of an API specification and when I
26:54mean an API specification it's not just
26:56open API specification it's things like
26:58aradozo it's things like which allow you
27:00to orchestrate an entire workflow right
27:02so it allows you to capture that
27:04simulate that whole thing so that you
27:06would be able to validate it's it's
27:09almost like Figma for API design if you
27:12will right where you can quickly
27:14uh do high fidelity prototyping and kind
27:17of execute your intent and validate
27:19whether your intent is what you need.
27:22Right? So that's one idea that we've
27:24been working on. Lots of other folks are
27:26also doing a lot of interesting work in
27:28this space. The next one is what we call
27:30as executable architecture. Uh the idea
27:33with executable architecture is that
27:36individual APIs is fine but across the
27:39several different integration patterns
27:41that I have. It could be uh restful
27:43integrations, it could be asynchronous
27:45integrations, it could be uh file-based
27:48integration, CLI based integration,
27:50several other forms of integration. How
27:52do I define all of that? Not in a
27:55document which is again inference-based
27:58but a document which is executable. a
28:02document that I can actually click a
28:04button, spin up my entire architecture,
28:08right? And then be able to kind of test
28:11itself, right? So, one of the ideas that
28:14you would see that is emerging is kind
28:16of using a combination of Arazzo
28:19specification with uh open API
28:21specification, a sync API specification,
28:24and then spinning up a mock for the
28:26entire system. So you have all the
28:28pieces that that basically spin up as a
28:31mock and then you use the same
28:33specification to then generate a test
28:35from it and so it gives you uh a set of
28:38tests that will run against the mock. We
28:40call it the closed loop uh test. And
28:43what this will do is it'll help you
28:45visualize if this is how you're
28:46envisioning your architecture to be
28:48whether it makes sense, right? You know,
28:51so before you've actually built a single
28:52line of code, before you even ask the
28:54agent to build anything, you want to
28:56kind of quickly validate your
28:58architecture itself, right? So that's
29:00again another uh I would say idea on top
29:03of harness engineering that would allow
29:05you to uh you know validate your
29:07architecture and keep this loop going
29:10right. So as as components get built
29:12they get plugged in but the overall
29:14feedback loop on your architecture to
29:17make sure that you're not drifting. You
29:19intended this to be asynchronous. It
29:21should not suddenly become synchronous.
29:23Right? Those kinds of things can be now
29:25validated at this level. Is that
29:27sufficient? Are we good with these two
29:30things? Is there anything missing?
29:35I would say there's one other important
29:36thing which is the governance thing but
29:39not the current style of governance that
29:42a lot of places we are seeing. What we
29:44want is essentially again a continuous
29:47governance which is kind of a control
29:49plane uh taking feedback and providing
29:52feedback to each of these. So just to
29:54give you a little bit more context, when
29:56I'm trying to do executable intent, uh
29:58let's say I'm going from a plain English
30:01intent to a executable specification, I
30:04don't want to reinvent things that
30:06already exist,
30:08right?
30:10How how does how does the agent know
30:12when it's going from plain English to an
30:14executable spec that this already
30:16exists?
30:19Today in a lot of organizations we don't
30:22have a single view of the uh API
30:26inventory that exists in your
30:28organization even if you have it's it's
30:30in lots of different formats which is
30:32not very friendly for an agent to
30:34understand
30:36right so imagine you had a kind of
30:39central repository of all your
30:41specification you don't need the details
30:43but mostly the metadata which an agent
30:46can understand and that can be fed into
30:48this upper cycle there executable intent
30:51cycle and so it can basically uh
30:54leverage what is already there not
30:56rebuild it so avoids duplication and
30:59stuff like that it can reuse schemas
31:01that already exists so for example if
31:03shipping address is already defined in
31:05your system you don't want to build a
31:07different uh implementation of a
31:09shipping address again right so all of
31:11those things can be leveraged back in
31:14this and also same thing applies at
31:16executable architecture level these all
31:18kind of feed into each other. So there's
31:20almost you can imagine a loop going
31:22around this whole thing, right? So you
31:25have executable intent, you have
31:26executable architecture, you have the
31:28harness in between and then you have
31:30governance which is kind of your control
31:32plane. So all put all of this together
31:34is what I think we calling as closed
31:36loop engineering. And this is
31:40I'm not sure if this is sufficient but
31:42it is uh at least something that we're
31:45all kind of building towards as we go uh
31:47to figure out if this can help avoid a
31:50lot of challenges that we are seeing to
31:52avoid kind of the toll booth right so
31:54just to again quickly summarize
31:58uh what we are saying is you want
31:59autonomous generation you want
32:01validation against executable
32:03specification you want any deviation to
32:06be detected and uh removed uh you then
32:09want the correction the sensors to auto
32:11feed in and then that leads to a
32:13continuous flow which allows you to
32:15trust the output before a human gets it.
32:18Right? So all of this happens uh before
32:21you actually look at it and so the trust
32:25in what the agents are doing would go up
32:27and hence probably you'll stop putting a
32:30human in front of an agent and slowing
32:32it down. Right? So I think that's pretty
32:35much uh what I had. I am uh
32:39I wanted to leave uh time for questions.
32:42So I think it's good time. We have 10
32:44minutes if I'm not wrong or 8 minutes
32:46for questions.
32:48Yes. Can someone please help with the
32:50mic?
33:00>> So my question is on the previous closed
33:02loop diagram that you just showed.
33:04>> Yeah. So what if we have an ability to
33:07treat that whole thing as a skill and
33:09then put it in a continuous uh
33:11self-arning
33:13mode? Would that be a good extension of
33:16improving that?
33:17>> Uh you will run out of context.
33:20If you try to stuff all of this into one
33:23skill, you will run out of context.
33:27>> That's my short answer. Got you.
33:34Yeah, uh really nice uh presentation. Uh
33:37so I had one question. You mentioned at
33:39one place u in your u kind of the
33:43structure you presented that whenever
33:45there's a mistake
33:47uh we would like the human to get
33:48involved there. Yeah. So with the uh new
33:52systems and AI becoming more and more
33:54powerful and uh all the experimentation
33:57going on will it not be an idea where we
33:59actually have some bit of intelligent
34:02autocorrection also built there and then
34:04if AI is not able to correct something
34:07then only human comes in the loop.
34:09>> Absolutely. That's that's the idea with
34:11basically that's why you're providing
34:13the sensors so it can selfcorrect
34:15itself. You don't necessarily need a
34:18human. You only need a human when the
34:21the agent is not able to figure out
34:23things. Uh but you make sure that you
34:26can provide uh both the guides and the
34:28sensors so that the agent can be
34:30autonomous to the extent. But I'll give
34:32you an example, right? What if you've
34:34given contradicting
34:36uh you know requirements in your prompt
34:40to the agent? What should it do? Should
34:44it self-correct?
34:48Yeah. Yeah, it can. It can still try to
34:50self-correct. But when it gets you into
34:52that situation, see that that trigger
34:54has to be there somewhere. Yeah. So that
34:56trigger has to be there because AI in
34:59the current form is highly likely that
35:02it will never come back to us with the
35:03LM support will never come back to us
35:05saying that okay, I'm not able to do
35:06this. Yeah,
35:07>> that's the problem I feel today is that
35:10the agent assumes right. Right? So if
35:13you gave a contradicting requirement
35:15like to make it very specific let's say
35:17in one place you've said that this
35:19particular value should be less than 10
35:22in another place you you've given that
35:24it should be more than 20 right today
35:27the agent will pick one of them and move
35:30forward right
35:31>> so you' give some guides that will tell
35:34it like hey don't do this when you're
35:36confused like basically pull the human
35:39don't so the the difference right is
35:41that Don't expect a human watching over
35:44you. But when you can't figure out
35:46stuff, pull the human, right? So that
35:49you uh you can like not make
35:52assumptions. Uh because once you start
35:54making assumptions and people figure out
35:56it's not what they wanted, then the
35:58trust factor doesn't kick in. When the
36:00trust factor doesn't kick in, then you
36:02will have one human standing in front of
36:03every agent waiting to watch. Right? So
36:06we want to get out of that loop that
36:08mentality and you want to let the agents
36:11do things and that's where you want to
36:13provide as much information you can but
36:16when you try to provide too much
36:18information again like you end up you
36:20know exceeding the context you end uh
36:24other kinds of problems uh and you may
36:26not get the results right so there's a
36:28lot of uh I would say skill involved in
36:31terms of optimizing the context that
36:33you're going to provide uh and when
36:35you're going to provide that uh but let
36:37the agent pull you when it's not able to
36:40figure out something rather than
36:41assuming and moving forward. But to your
36:44point, absolutely you'll provide the
36:45sensors, you'll provide everything so
36:47that it can self-correct, right? You
36:50don't want to be waiting and watching
36:52over it. Uh but that's not always
36:55possible like the example I gave you
36:57where you've given contradicting things,
36:59right? Or there may be other regulatory
37:01kinds of things where it's you wouldn't
37:03want it to just make
37:09Yeah. Okay.
37:10>> Um, hi. So, I really like how we are,
37:15you know, uh, putting this together for
37:17APIs because right now in my
37:19organization, we are we have something
37:22called maturity index for each of the
37:24repositories. So, this stands first I
37:27guess the guides and the sensors and
37:29everything else should be put together
37:31for APIs and then separately for UI. My
37:34question is regarding the guides uh
37:37where uh the agent plug-in uh has skills
37:41and MCP. What do you specifically mean
37:44by MCP in this place? Because whether
37:46it's a developed MCP or you are just
37:48providing the guidance to create that
37:50MCP along with the API.
37:52>> Uh so there are several different forms
37:54of MCPS that you can plug into it. Uh so
37:57anytime like basically an agent is going
38:00from a prompt to generating the code for
38:03you it'll need a set of uh inputs right
38:06so a language server for example is an
38:08MCP that you could provide to it right
38:11but you could also have an MCP sitting
38:13on your control plane that the agent can
38:16talk to to figure out like hey am I
38:18doing uh something that I should avoid
38:21right uh from uh let's say uh if you see
38:25like a an API's unstable. Should you be
38:28depending on that API?
38:30>> Okay.
38:31>> Right. You may not want to depend on an
38:32API which is unstable, which is not or
38:35deprecated. That's even better example,
38:37right? So if an API is deprecated, you
38:39would want that feedback to go in, but
38:41you can't stuff all of that in up front,
38:44right? So you would provide uh you know
38:46MCPS to kind of make those decisions.
38:49>> Okay. So we are talking about real MCPs
38:51that do the job of implementation and
38:54correcting and all that right
38:56>> MCPs for mostly providing feedback to
38:59the agent or guidance to the agent so
39:01that they can kind of selfcorrect.
39:03>> Okay. Yeah. Yeah. Understood.
39:04>> Or produce things right in the first
39:06place.
39:07>> Thank you.
39:08>> Uh so really loved the presentation nar
39:11and especially the analogies of the loom
39:12and the traffic lanes. Uh brilliantly
39:15done. uh and I was actually I worked on
39:18the Citrix API platform long back 2018
39:2019 and I just wish I could take all of
39:22this and go back in time and you know
39:23use all of this. Uh coming to the
39:25question uh to me looks like this takes
39:28care of a lot of the design aspects
39:31implementation aspects even testing
39:33where do you think uh you know runtime
39:35characteristics like scale performance
39:37fit into this whole you know framework?
39:39>> That's that's a brilliant question. So
39:41when we saying the governance piece
39:43that's also looking at so it has all the
39:46observability aspects into it and that's
39:48kind of where you want to have these uh
39:51feedback loops between them right expose
39:53an MCP on your control plane so
39:55everybody else can tap into it and you
39:58know you basically are getting feedback
40:00from uh monitoring uh from your
40:03governance uh sorry from your
40:04observability systems into this so you
40:07know what's happening in the production
40:08environment at runtime as you scale
40:11things but also what uh at least we've
40:13done in a lot of cases is built a lot of
40:16that stuff here right so when you're
40:18individually designing an API you can do
40:21a lot of resiliency testing you can do a
40:23lot of things uh for example if a
40:25downstream service is down how are you
40:27going to behave you know you have you
40:29implemented circuit breakers correctly
40:31how do you validate that uh so both as
40:33part of sensors and guides you can kind
40:36of so guide would be essentially like
40:38hey for for this kind of an API I I want
40:40you to fall back to asynchronous, right?
40:42So instead of doing 2011, do a 202 uh
40:46and then respond back with the monitor
40:48pattern, right? Like that would be like
40:50a best uh practice that you would feed
40:52into uh the the agent, right? But then
40:55you need to validate whether it did
40:57actually implement it exactly in that
40:59way or not, right? Is it's given you a
41:02monitor link, but is the monitor link
41:04actually when you hit it eventually when
41:06it completes, does it give you back a
41:08result? Right? So a lot of those kinds
41:11of things at an individual API level
41:13today we already have the capability to
41:16do that. Right? But at a scale when
41:18you're trying to look across like in my
41:20case 40,000 services then you
41:23essentially want all of that data coming
41:25into your control plane and then feeding
41:27it back into all the agents. Right? So
41:29that's kind of another example of the
41:31MCP that kicks in.
41:33>> Thank you. That helps. And if I may add
41:34a part B to the question, uh if let's
41:37say you're specifically designing and
41:38implementing APIs to be consumed by
41:40agents in that case, do you see this
41:42framework evolving? And
41:44>> absolutely. So there are a lot of like
41:46AI quality metrics, scorecards and
41:48things like that that you build into
41:49your governance uh which essentially
41:51helps you understand whether the API
41:54itself is ready uh that you want to
41:57expose to an agent or not. I think
41:59there's a lot of great work that uh I
42:01don't know Eric and Frank the folks from
42:03Gentic are doing. Uh even Kinlane is
42:06doing some very interesting work in that
42:08space. So uh there's a lot of folks who
42:10are trying to figure out uh whether like
42:13how do I score how do I guide whether my
42:16APIs are actually ready for the agents
42:18to be consumed.

About this transcript

This page contains the full transcript of Fost India 2026 - Restoring Trust in AI-Native Development | apidays India 2026. by apidays, generated from the public captions YouTube serves with the video. The transcript has 6,940 words across 998 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.