Get started on Sui through Agentic Engineering | Raphael Chia at ETHGlobal Tokyo 2026

Hello everyone. The time has come, so I guess I'll start. I'm very happy to be here today. My name is Rafael, I'm from Mysten Labs. I am a solution implementation engineer and have been working at Mysten Labs for about a year.

My daily work is either integrating solutions with partners or speaking here, talking about Sui, discussing interesting topics, and stimulating discussions with you, with developers like you. Today I want to talk about agent development on Sui, or more precisely, how to get more quality and less " quality and less " garbage". True? Why am I talking about this? Stanford University conducted a large-scale study involving about one hundred thousand developers.

And they discovered something very important. They confirmed that AI confirmed that AI coding increases productivity. Despite all the mistakes associated with artificial intelligence and technical debts. By the way, an interesting fact: they also found they also found that when using AI, productivity in new projects is significantly higher than in old code bases. I'm sure some of you have already encountered this, especially during hackathons where you often work with new codebases, and that's where AI definitely helps a lot.

We can agree with this. So, what is the real goal of AI engineering? Who even thought about this ? Who thought about what the goal was? What is the ultimate goal?

Now that everyone is using AI, I personally see three goals: the first is goals: the first is to solve complex problems. This is a very important goal. The second is important goal. The second is to perform a large amount of routine work accurately. It's not just about generating a bunch of code.

It's not just about releasing a lot of code, but doing it with quality. And finally—no “ finally—no “ garbage” and technical debts. True? After all, what's the point of solving complex problems and producing a large amount of code if the result is only " only " garbage"? It works in production, but can you confidently say that you control your code, everything that happens, and that you consciously chose the architecture?

With "garbage" and technical debt, you can't say that . You can't confidently say that you have everything under control and understand your architecture. So, that's my opinion, right? These are the goals of AI engineering. And there's actually another very important goal, which is I'm sure some of you or most of you have seen this phrase before, right?

The AI ​​tells you that you are absolutely right. Yes? That's where it's from, friends. We do n't want that, do we ? So, that's one of the biggest goals.

We don't want to see this, in fact we want AI to tell us when we are wrong. Really, what's the point of him just agreeing with us? So, these are some of the goals of AI engineering. And how do we get closer to these goals? Yes?

This will be the main topic I will talk about today. And this is context engineering context engineering . And again, I'm sure most of you have heard of context engineering, right? This is a term that is often mentioned. He is quite popular.

So the idea is that if the only way to influence the output of LLM influence the output of LLM is through your context window and your input, why do n't we spend more time managing the context window, managing the input? Yes? I'm sure we all agree, because none of us can really configure Astra 6 or Opus 5.5 on the fly, right? We cannot change the parameters.

What is the only thing that will affect the output? This is your input and your context window. Yes, for ordinary users like us. So, if that's the case, you know why we don't spend more time and effort on managing the context window and controlling input? Yes, so this is all based on this idea.

I'm sure you've seen these words before: context shift, context degradation context degradation , "garbage in, , "garbage in, garbage out," right? And honestly, if we're the ones generating, we're the ones creating the queries, we're the ones using AI in our engineering, right? And all we do And all we do is hope that the result will be good. Essentially, it's like a casino. Isn't it?

We are just gambling. We just hope that at the end of the day we get a good result. Yes, but we do n't want that, right? And speaking of casinos, I think query generation and casinos have a lot in common. Because we buy chips at the casino.

When you create a request, you purchase tokens. It's the same thing , man. You spin the slot machine, you press " press " generate". This is essentially the same thing. You can hit the jackpot, you can get a working code.

Truth? In the casino, you get attractive lights and animations. Yes, of course. Great idea. This is what you get during prompting.

And the casino always wins, the casino is always in profit. All AI providers always win, right? There are so many overlays here, and that's what we don't want. We don't want prompting to turn into a casino. We want to control our results.

Truth? So, I'll just talk very quickly about two ways to manage context. The first context. The first is frequent intentional compaction. And the second compaction.

And the second is research, planning, implementation. Truth? So let's look at what this all means. So, frequent intentional compaction: a usually naive way to start prompting is “ re-steering”. So what is " redirection"?

Truth? Imagine you have a context window you have a context window . You communicate with your AI provider, right? You have a context window, and the result you want isn't there yet, and then you tend to write something like, "Oh no, do X better." "Or is that not good enough, maybe it's better to take approach Y" to take approach Y" .

"Or what's the difference?" Use the best method, you know." As you can see, when you use these prompts, you are essentially " prompts, you are essentially " redirecting" the current context, right? Redirect to make everything right. And this is the easiest way to get started with prompts.

I'm sure all of us who are into debugging are familiar with this, right? We know all this very well . And it's called " called " redirecting," it's simple, but it bloats your context window. So, imagine doing this five to ten times. Now you have five to ten different incorrect methods in your context window incorrect methods in your context window .

And every time you send your next message, your next prompt, the entire context window is sent with it. So you see how it starts to, you know, clutter your context window with inaccurate information inaccurate information . Truth? That's why I want to talk about intentional compaction. So, what is intentional compaction?

It's as simple as giving a prompt: "write everything to a file in markdown format." Be sure to note the approach. What we are doing, how we will move forward, and what the current problem we are working on is. It's that simple. There are no hard and fast rules here.

There are no fixed prompts. Actually, compacting is when you say, "Put everything we've done into a markdown file. I'm going to move to a new context." This is intentional compaction. True?

And again, you might ask: how often should you do this? Well, actually, again, when you see that it's time to move on. Okay, all jokes aside, you'll understand when it's time to compact to compact , when you start coding a lot, when you work with AI work with AI engineering, right? Maybe after three or four right? Maybe after three or four unsuccessful requests you'll realize it's time to move on.

This comes with experience. This comes with understanding the code base. True? So, why do we need compaction? Because we know that the size of the context is limited right now.

What is the most common context size for the average user right now? 256 thousand? 1 million? Some have 1 million, right? Is there something wrong with 2 million?

I don't know, but do we need that much? Usually 256 thousand or 1 million are standard figures standard figures , and they are limited, right? And everything takes up space in your context window. Your input/ input/ output operations, your modifications—all of this takes up space. Even tool calls tool calls , especially those.

If tool calls are not optimized, they take up a lot of space in the context window. So the goal is context window. So the goal is to keep the context window at context window at 40–60%. And this is what Jeffrey Hinton is talking about. Who here knows who Jeffrey Hinton is?

Jeffrey Hinton, some of you know, right? He is a very prominent figure in the field of AI. He does a lot of research. He pushed the boundaries of AI pushed the boundaries of AI engineering when LLMs were new. True?

So, he is a very big figure. You can google it. But the golden mean he discovered is to stay within 40–60% of stay within 40–60% of your context window. That's when you start to notice context degradation, context "drift," and so on. Right and so on.

Right ? So, 40–60% is the ideal range. What are the goals of frequent intentional compaction? Reduce context drift, context degradation, and improve output quality. And it's definitely not to save tokens.

True? If you're just using this to save tokens, there may be a better way. But we know for sure that there are different ways to save tokens. That's not the purpose of intentional compaction, right? We just want to improve the quality of our work.

So, this is for our frequent conscious compaction conscious compaction . Next is research, planning, and implementation. It's pretty simple. It's a three-step process, right? And it is quite clear in itself.

So these are three different stages, and most of the work is actually done in the research and planning stage. Isn't that right ? So I would say that up to 85% of your time should be spent on the research and planning stage. Implementation should be as simple be as simple as clicking "create." Isn't that right?

So let's see what it looks like. And, you know, the RPI is designed to do a very large task at once and accurately. Is n't that right? And let's assume you've already completed the research and planning stage, right? So, when we talk about research, what do we do?

We want to understand the system, the data flows, the architecture, the stack, find the relevant files, the configuration, maybe your CI configuration, how you deploy, know what Kubernetes environment you need to pay attention to, and all of that context—it's all factual context. You know, when we do research, we want to know facts about the codebase facts about the codebase . We don't want to look for mistakes, improvements, or shortcomings. Isn't that right or shortcomings. Isn't that right ?

This is not the purpose of the study. Research is simply stating all the facts about your codebase. Isn't that right codebase. Isn't that right ? And this is the first step.

Maybe your result could be something like research 00.markdown, right? And then we move on to planning. So, what is planning? Basically, the goal is to find and outline all of your relevant implementation.

You can include important file names, code snippets, and even be clear, very clear about your testing steps. What is your definition of completion? What do you expect after this implementation is deemed successful? Isn't that right? So, this is the planning stage.

You can output this, for example output this, for example , as plan feature x.markdown. So, so far we have two markdown files, two results. Isn't that right? Research and planning.

And assuming you did everything right, implementation will be simple. You're just saying to go to the first markdown file and execute, well, let's say, planning login integration.markdown. And that's it. Implementation should be extremely fast.

It should be, well, short after you've done your research and planning. Isn't that right ? And that's all you need to do to implement. So, it's a three-step process. This is a workflow, and there are no hard and fast rules.

Isn't that right? It's not that there 's any magic in improvisation. There is no magic in improvisation . It's just your process. And this RPI allows you to stay in control of your architecture and solutions.

Isn't that right? You don't go through the agent cycle to find out about bugs only after they go into production. Is n't that right? So the purpose of the API is n't that right? So the purpose of the API is to control what you decide.

You know, he doesn't follow any specific guidelines. It should be general. Sometimes, just sometimes, you feel like you don't need to do any more research. Isn't that right ? When you have completed your research, you may be doing a lot of planning and implementing, planning and implementing.

Isn't that right ? You don't always have to do research, but, you know, you don't have to stick to anything specific. This is just a recommendation. Is n't that right? So, a few reminders before we wrap up: AI doesn't read our minds.

At least for now. Is n't that right? Who knows what Sam Altman will release tomorrow. But AI doesn't read our minds yet. So please don't—for those of you who are maybe new—don't create these prompts and expect very good results, okay?

They can't read our minds. So try to be as accurate as possible, provide as much correct context as possible. Don't just say "fix it, do it as best you can, no mistakes," okay? And yes, that's actually the goal: two methods for you to improve results and reduce errors. I have a few links here, but don't worry, I'll post them to our post them to our Sui Discord group and you can check them out.

I went through all these links and I had this idea, which is why I started this topic. Isn't that right? But before we wrap up, some of you might be asking: what about the part about Sui? Remember, the first slide was " first slide was " agent development with Sui" agent development with Sui" , right? So where's the part about Sui?

That's the part about Sui, right? So, if you scan the QR code, you will be taken to the official MCP Sui server official MCP Sui server . And as simple as it sounds, that's all you need to get started. So, we talked about how to formulate requests correctly, how to establish a good process, how to reduce the number of hallucinations and improve results improve results ? Using the ?

Using the Sui MCP server will further reduce your hallucinations. You don't even need to know what our technology stack is. Just connect your agent to MCP Sui and you'll find out everything. It is connected to our official up-to-date documentation. You can find everything you need there.

You can be sure that if your agent gets the information from there, then everything will be fine. I'm not just going to talk, I'm going to do a very short demonstration. Do we have time? We actually have a lot of time, so I'll do a very short demonstration to show that this should work, okay? So, I have a session in the cloud I have a session in the cloud .

I'm just asking, am I connected, right? Yes, there is a connection. So let's try. Let's check what the difference is when MCP SweetOps is connected. Without even knowing about the stack, right?

I start with the MCP Sui documentation. And it's basically like this: if you have any idea, anything you want to create for hackathons, if it's related to Sui, just plug it into the MCP, let the agent do the work, and rest assured that there will be significantly fewer hallucinations. Yes. He gives you some advice. Decide what exactly you are selling.

Number two, kiosk basics. What is a kiosk? You didn't know, but now you know, that there is such a thing as a kiosk. Yes? In Sui, we have kiosks, and a kiosk is a primitive that is used to handle all kinds of market integrations.

Yes? It will tell you about shared and private objects. You don't even need to know what it is. You don't know what you do n't know, right? But the documentation will tell you what to look out for .

Here's what I mean when I say: just plug this into your MCP and you'll find everything related to your idea to start developing. I think it's very simple and very quick to get started. And I highly recommend everyone just start. If you are new to Sui, of course. Even if you are not new to Sui, you can use the Sui documentation to learn more.

And so, hopefully, you can integrate and make something happen. Raise your hands, roughly who is going to build on Sui today? Good. Almost everyone, huh? That's good.

That's good, right? So, if you already know what you 're building, what stack you're using, and what primitives you're using to implement your project, of course. If you don't know, get connected and just ask. But just ask. But , yeah, that's all for my presentation today presentation today .

E Five more minutes. Actually, three more minutes. Five more minutes. I am ready to answer to answer any of your questions, if any. I will try to do everything I can.

But if not, then thank you.