280 – Open App Builder, PLH and AI agents

[00:00:07] Michele: Hello and welcome to the IDEMS podcast. I’m Michele Pancera and I’m here today with David Stern, one of the founding directors of IDEMS.

How are you, David?

[00:00:18] David: I’m doing well. How about you?

[00:00:21] Michele: I’m doing great.

[00:00:22] David: We recently discussed your interest and engagement in building these AI agents for STACK Authoring, and I wanted to talk now a little bit about some of your other work and how this might relate, the work that you are doing related to the Open App Builder and in particular how this relates to some of our work for Parenting for Lifelong Health.

[00:00:49] Michele: Sure. There is a real comparison there, even though authoring STACK questions and authoring for the Open App Builder are two completely different endeavours. But what I would like to achieve with the STACK assistant, one of the things I would like to achieve, is to just make authoring have less barriers to entry so that more potential users of STACK, not just users, but authors of STACK, could actually use the system.

And something similar applies to the Open App Builder and the PLH work that we are doing. With the Open App Builder, in the version that we have at the moment, it is just not trivial to author. It has so much potential and we are doing so much work with it, and my understanding is our partners are satisfied with what we do. But again, the authoring is just a job one cannot just easily learn to do. But the complex parts of that job could actually be, I guess, quite easily managed by an AI assistant. Is this the direction where you wanted to go?

[00:02:23] David: Well, this has been the direction I’ve wanted to go for years, but yes, the fact that AI agents could help reduce the complexity of the authoring process is not an accident, it’s by design. The design of the authoring process is to try and extract out what is essentially decision making and authoring decisions from, if you want, underlying language, which is being used to implement.

So, in particular, one of the problems that relates to this is the fact that a lot of social impact technologies become obsolete very quickly because the technologies they were developed in become outdated, and therefore, either they need to be rewritten from scratch or, what more often happens is that the funding runs out and they just die.

And so separating out the underlying implementing technologies from the substance of what is the intervention, if you want, the actual apps or chatbots and so on, was a deliberate design decision. And to do so in such a way that we are not oversimplifying, but we are creating a system which deals with substantial complexity and therefore requires mathematically minded people like yourself, like Esmee, like others, to build good structures, was, again, by design. Not because we want to create jobs for mathematicians, but because actually those mathematical structures are exactly things that can be well suited to AI or building automated systems in the future, not automated, that’s the wrong word, to build, I suppose, these AI assistants on top of.

So this was always what we were designing for, even before these AI assistants became possible.

[00:04:33] Michele: Yes, maybe I should mention at this point for the audience that one of the obstacles that we have had up until now for the implementation of AI agents for Open App Builder is that we mainly work with spreadsheets and that’s where we author our apps. And that is very convenient, it’s less heavy on the user, the visuals of the code – I’m not sure I want to call it code – the visuals of what we’re doing is always consistent, and many other advantages.

[00:05:15] David: So maybe I should clarify, the spreadsheet authoring, this was taken and learned from Open Data Kit, ODK, where the spreadsheet authoring of surveys became extremely popular and very successful. And there’s many other cases that have taken up this idea of elements of authoring in spreadsheets.

But I want to be clear that the spreadsheet authoring was never the key point. The key point was by authoring in spreadsheets, what you are actually doing is that you are storing everything as data. So it is the fact that, really, you are just working within and you’re populating data structures.

Now of course code is data when you parse it enough, but the structure of this data and the way you structure this data is a very deliberate choice in how these systems have been conceived.

[00:06:15] Michele: Yeah, and this spreadsheet, let’s say visual, was not very workable for AI models. AI models work better with plain text, for example. Now, of course, there could be a nice translation from one form to the other, but the fact that we now have the potential of multi-agent systems means that we, again, potentially, can create specialised agents that would then be very able to understand the incredibly complex work that lays behind the Open App Builder, and then make the interaction between them actually useful.

For now, the only thing that we attempted to do was not a multi-agent system, but just an AI documentation system that would know about the main components of the Open App Builder and would help an author when necessary. But that is very, that’s a very low hanging fruit, let’s say, but also far from what we could achieve.

[00:07:42] David: No, absolutely. We are still very much at the start. We need to build out the system, but the vision being that the data structures that we are building are exactly aligned with data structures that could combine human and AI agents working together to author these systems. And that’s really what we’re wanting to work towards.

It’s this idea that we can really, we are not just looking at building systems where you can pass on technical tasks to AI agents and get them to write code for you, but we are looking for systems where the language that humans and the AI agents are interacting on is at a data level, whereby the transfer of information, the control of information, the actual exposure of decisions can be really more visible and where human control can be inserted on the things which are important and which humans care about, and the AI agents can be doing their thing on the things which are less important. And that differentiation could be very different in different contexts, so it’s not predetermined, but it is something which can emerge in each individual project or collaboration.

And I use the word collaboration there because it’s not just collaboration between human agents and AI agents, but it is this idea that we can have collaborations across projects which can be facilitated and enabled by the technologies.

[00:09:32] Michele: Yes, those are a bunch of very important insights and maybe let me just highlight in other words. It will never be about automating and substituting humans, but actually exactly the opposite. It will always, from our side, be about empowering humans to spend their time and energy on the actually important decisions.

[00:10:02] David: That’s a really good way of articulating it. It’s about using the AI agents to enable the people responsible to take responsibility for the things that matter.

[00:10:15] Michele: This is exactly what we are trying to make happen with the STACK assistant and the Open App Builder system has always been like that, and possibly even more with the multi-agent systems that we will build.

[00:10:33] David: Yes, and so these are two instances where we are still in early days of building out these AI enhanced systems for authoring, but it’s really nice to see how the technology is just coming of age, not to think of the AI agents as replacing authors or taking control of the authorship process, but really enabling authors to take control of their authoring process.

[00:11:03] Michele: Yes, that’s exactly the frame that I like. David, is there something that we didn’t touch during this conversation that we should mention?

[00:11:15] David: There’s one thing that I was thinking as we were discussing. When you started authoring for the Open App Builder, this was way outside your comfort zone, this was something which, at first you thought – we discussed this in a previous episode – what was I doing recruiting you for this task? But as you got into that authoring – and you’ve now become one of the key members of the team who does quite a lot of this authoring – I think there was a recognition that this isn’t the same as programming.

And so, I guess that’s something I’d like to dig into and say, this isn’t an easy no code solution, you know, drag and drop, put things together, but this is not programming either. This is something different. Do you think you can articulate a bit your feeling of that now?

[00:12:09] Michele: Well, let me first give a nice anecdote exactly about what you’re saying because I’ve been training a few interns from Mali about how to use the Open App Builder system, and that has been a very interesting process, especially because these are very talented people who have previous experience in some kind of coding, and what they expected when they started to learn the Open App Builder system was just another way of coding, and it was just fun to see their reaction once they saw the spreadsheets.

What that looks like, as you mentioned, it looks like data. Now, it could look like data a bit more potentially. It looks like an in-between, some parts, in some cells, we see code, but it’s really a different beast. And at first glance it’s just hard to wrap our heads around it because we never interact with anything like that. Should I say more about this?

[00:13:39] David: Maybe go beyond what first glance is. So, once you get into it, why are we doing something which is different from coding, what is it that you know comes out? What have you found?

[00:13:51] Michele: I have to actually think about this. Well, I’m sure I’m going to say this wrong, but let me try. So it’s not like the Open App Builder system doesn’t contain code, it contains plenty of code. The authoring is mostly thought of as data. And that means that once we build, once we author something for the Open App Builder, then it can really pass from one system to another, maybe from one deployment to another, but also from one system to another, exactly because of the fact that it is more data than code. Am I encapsulating what you were thinking about?

[00:14:45] David: Well, I don’t know, this is the thing. I’ve not spent time authoring. I have spent time conceiving the system, imagining it, but I’ve never had that experience as an author, really. I’ve done little bits here or there when urgent tasks have come in, and I had my own opinions about that, but I’m interested to know what you are finding. So you are finding that, once it’s stored as data, you then think of it differently, you interact with it differently. That seems to be what you are saying.

[00:15:16] Michele: You definitely think about it differently and it doesn’t look like a piece of code of an application anymore, but something that it’s fed into a system, just like data can be or not be part of the information of a working system. I know I’m not making much sense here, but it just feels like something that is more portable, more universal than a specific code.

[00:15:54] David: Maybe let me see if I can reframe something on this. When you say it’s more portable than a specific code, it feels sort of language independent almost, it’s the core of the meaning without necessarily being tied to a language. Does that articulate some of this?

[00:16:15] Michele: Definitely. Yeah, that’s a good framing. It’s information that can then be, well, not only visualised in different ways.

[00:16:26] David: Interpreted in different ways. So this is the key, this is really interesting that this is how you’re framing it. And it’s really interesting that we’ve gone through this discussion to get to this because this is, again, by design, this is not by accident. But the idea being that what you are seeing is what you care about, so it might be, at the moment we don’t have this as we would like, but there could be very different views on the same data where an author who cares about the content might see things differently from a developer who cares about, well, how that content is really displayed on the screen, on the apps or whatever it might be.

But what you are saying, which I think is correct, is that in some ways both of those information are there, but there are elements of separation which have been achieved whereby data being displayed, or the data you are interacting with as an author, really depends on your viewpoint.

And that’s something where I would argue at the moment we are doing that to some extent because you need to learn how to author because there’s only one viewpoint, we don’t have multiple viewpoints. But the AI agents and what we should expect to get in the future is exactly this element where you should be able to see what you care about and then actually have AI agents who help you to sort of think, well, what does this actually correspond to, or what level of generality does this exist and so on.

That’s a level of complication, which really matters to design good, complex applications, but it is not something which all authors want to interact with all the time. And this is exactly where, once we integrate the AI agents into this properly, then this should enable some of those decisions to be made consistently, where individual authors don’t need to understand the full complexity, they just need to know what they want to change.

[00:18:49] Michele: Yes, and choosing the proper visual depending on what the interest of the author is. I can clearly envision that, I can clearly see how different authors may just want to have access to different parts of the data and have that displayed to them and be able to interact with the data differently. That seems very powerful.

[00:19:22] David: Yeah. So, it is really exciting to me. Actually, you know, really we conceived this, myself and a couple of others, we conceived this six years ago now. About 2020 is when we, well I, first started thinking about this and designing this system exactly because we came across this problem that when developing apps in low resource environments for social organisations, every group that wants to use it, actually wants to change it. They want to make it their own in specific ways.

But they don’t want to edit the whole thing, they only want to edit the things that they care about. And the systems to be able to do that and have those layers of complexity didn’t exist, and the simple truth is, they still don’t. But we are getting there, we actually understand the problems that need to be solved, we just need to now have the resources, have the time to build out these systems, which will enable this to work in different ways. And it’s really exciting to see that six years ago, when we started this, we were designing for systems that didn’t yet exist. And now these multi-agent systems that we’ve been talking about are exactly part of the tool which is going to make this possible, or the tools that are going to make this possible.

[00:20:47] Michele: Part of why this is exciting is it’s just a different kind of, a different way of framing technology compared to what we’re used to, to big tech.

[00:21:00] David: Yes. Instead of tech being something big and centralised, tech could become something small, very customizable, with lots of local variants where there’s ownership, there’s real ownership by communities that understand their context. Anyway, that’s the dream, we’re chipping away at it one step at a time, but we are making progress.

[00:21:24] Michele: I’m sure we’ll have other podcasts about topics like this in the future because we are really making progress here. For now, I think this is a good moment to close the episode.

[00:21:37] David: Absolutely. Thank you so much for this and for, again, discussing the work that you are part of, and really great to hear and see the progress.

[00:21:45] Michele: Thanks to you, David. All of this is incredibly interesting.