AIも空気を読んで動く時代に？ LayerX・名村卓が考える優秀なAIエージェントの条件
Oh, Mr. Arisawa. Mr. Arisawa has agreed to this.
I came to the trial once, but Izumin couldn't participate in the trial.
It's more like a back-end, so I was wondering if it would be okay, but I probably couldn't do it.
I think Alistair-san is probably in the enabling team. Well, he might be in the product team.
I wonder if it starts with an application or a product.
What do you think? He used to do a lot of infrastructure, so he's been doing it for a long time.
I wonder what this is. It's a gritty, more gritty, platform-type engineer. I've been doing this since the on-premise era.
Did I not go to Izumi for lunch? I think I went to Izumi for lunch.
I feel like I've been to a sushi restaurant. I feel like I've been to a lake, but maybe it's just my imagination. Maybe it's just my imagination. My memory is a little fuzzy, too.
Alright, ciao.
I think it was around August when I did the trial run. And when I did the trial run... Ah, but it was before that.
We'll see how it goes.
That's how it is. There are quite a few strong people coming in. The situation may change because various things have been decided.
How is the Agent system? Is it going well?
Well, it's not like it's going to do what I say, it's like... It's like... What is it? It has a lot of uncertainty about the process.
Yes, yes, yes.
I see.
It's not in sync. It's not in sync, and there's a lot I can't do.
It looks like a stateful application, but it's not stateful at all. It's a lie. It's a lie stateful. It's super stateless, but it's a stateless thing, and it's a stateful thing called chat. I'm trying to make it come true, so it's impossible to say it's impossible, with the API design. I think it would be nice if it could be a little easier.
Every time I do a state recovery, run it, submit it, wait for the next update, and then put the sub in again.
Well, that's that.
It's a piece of cake, isn't it?
This is stateless, so I'm doing the human in the loop right now, but it's a stateful stateless. The human in the loop is a bit complicated. You return to the user, wait for the input, update the sub, and proceed.
That's right. Well, that's normal, isn't it? That's normal, so it would be nice if we could realize that state. I'm working on Temporal right now. Temporal has a lot of limitations. I don't know what to say. The size of the payload is up to 2MB, and there are many things that can't be done in the activity.
I couldn't call it AISDK because I couldn't do a lot of things in the job step of the activity team. I think it's a completely Node.js problem. When creating a sandbox environment, The access is cut off, the temporal. It's a pure JS environment.
Oh, right. Activity. Workflow... I can't even call it a workflow? Maybe it's...
Can I read it? Can I go to the activity?
I see, the implementation of the activity is... Workflow... Is the workflow compiled into the package?
I was told by Node.js that there is no such thing as a transform stream in Activity. What? Node.js doesn't have such a thing?
I'll look into it a bit more.
I'm just proxying.
I wonder if you can't read the environmental variables. Can you read environmental variables?
I see, I see. So the activity itself is a worker, or rather, it moves in the environment normally, so it can go. Then, well... I can handle the stream, but I can't handle the workflow, so that's a bit... It's a lot of work. Activity... Activity has in and out, right? It's being proxied.
I don't think you can give such a difficult thing to Activity. Even if you think about the message passing of the workflow, I think there are only things that can be done in JSON.
Well, if that's the case, that's fine.
I see, I was thinking too hard. I thought the activity would be made into a webpack, but it was just a workflow code that was made into a webpack.
I can't read the workflow.
The workflow is an orchestration, so it's not going to be difficult.
The activity is in the worker, so the activity in the worker instance ... Activity ... I see. I see, I see. I was making a big misunderstanding. I see. I understand. But, recently, Temporal's... When making an AI agent in Temporal, I thought it was incompatible with AISDK, but I can't use Stream or anything like that.
Well, it can be handled in the activity of the agent. I was handling it with API K, but it can be handled directly. If it can be handled in the activity, There is no problem at all.
In that case, the stream needs to be processed in the Activity, and it must be... I have to return it, so I can't do punctuation processing in the stream with Activity. I think that's a bit of a constraint. Well, but... Step... Yeah... AISDK automatically executes the steps, so you can return it one step at a time.
Also, I think there will be a restriction that says you can't make the tool call automatically. I don't know if I should do a tool call in an activity, or if I should do a tool call in an activity.
And it's on YouTube. Temporal. Temporal's official website is on YouTube.
This is a demo of how to create an agent in Temporal. For the time being... After receiving the message, I thought it would be better to temporize the process and do it, but according to this, the workflow of the entire agent loop has been changed.
Oh, there's a key.
At first, I thought I would use Temporal's workflow for processing after receiving the message, but if it's an official example of Temporal, I don't use it because it's an AIS, The entire agent loop, the entire thread is expressed in one workflow.
It sends a signal and handles the event. It locks the state in the thread into the workflow. In the workflow, it receives a signal, receives a message, starts an activity, receives a result, and processes it as if it changes the workflow state. So, the flow state management code is a bit complicated. By doing so, while maintaining the state of the entire thread,
It's like, you can move forward. The workflow has been running for a long time in the back. That one thread unit. If you receive an event message, for example, with a Slack handler, you can send a signal to the active workflow. It's like processing. When a tool call occurs, after processing the message, the tool call from the AISDK
When it comes, you receive the content of the tool call in the workflow yourself, in the event, and the workflow reads the activity of the tool and takes the result. It's like processing a message in an activity that returns to the AISDK. Well, it's like that, so I don't think it's bad, but it's pretty bold.
When you want to insert a human in the loop, you can interrupt the tool call. This tool call can be used to make sure that you hit the Here, When, In The Loop. It's easy to do. All you have to do is wait for the state before executing the tool call.
I often think that it doesn't have to be Temporal. There must be a simpler one.
I just want to do state management. I feel like it's a bit of a clumsy Temporal runtime. I wonder if it's that. Well, but I thought it was a little disgusting that the workflow was web-packed.
Well, I guess that's about it.
I wonder if this is the best.
Ok, that's about it.
Does this mean that the Activity is moving in a place other than the worker's sandbox?
I have to make sure that it doesn't get mixed up in the workflow.
Something like a method.
I see. I understand, I understand, I understand.
It's Tyson, yeah. I think you can just look at the concept. If you look at the screen of Temporal in the middle and see that it is executed like this, you can understand that I want to do something like this. Even if you don't look at the code, you can get an image of what you want to do. I see, I see. That's how it is. For now, I want to coexist with the web and Slack.
I'd like to make it possible to sync it. There's that, too. The so-called LLM base, AgentLogic. If you receive a message like this, you have to do something like this. It is possible to make it as common as possible, so that the engineers who write the agents don't have to be too conscious of the web or Slack.
I hope to be able to draw something like that.
That's all.
Yes, that's right. When you start doing that, you want to do it temporarily. There are people who do state management properly.
I wonder what the leader is like. For example, even if you turn off the browser, the consumer stream will work properly until the leader completes it. If you make it valid, it won't be aborted. Well, it will be timeouted, but it won't be aborted unless you die in the middle of the server.
I think it can be restored.
I don't think I'll make a stream for that. If I were to make a back-end version of Temporal, In this case, the stream is probably a shared stream, and this thread is a resumable stream. I was like, I see. ResumableStream has a Redis streaming in the background.
Pub, sub. And I share the stream. So I replay the stream that has been updated elsewhere on the web.
The implementation was done properly in Resumable Stream, in the form of an AI output. There is also a sample. Yes, yes, yes. It is now working properly in AIS-TK.
If you play a stream, like a resumable stream, you can stream it on the web front. Actually, this is using the system of JSON SSE, so-called JSON stream. It's a JSON server-side event. It is supported by AISDK. When it comes to a resumable stream, we use JSON-SSE.
It has been recognized and converted to the UI stream and the message of the use chat has been updated in real-time. Using this, we can stream it in the back and put it on the front. I will resume it there and play it again. So, in the use chat, I will use the part where I post, but I probably won't use the part where I receive the result.
I think that's how it's going to be. I still use Temporal in the back end. I don't know how well Resume works, but if you do Resume, you can access the stream for Resume.
There is something called Resume Existing Stream. One stream ID is probably enough. If you have one stream ID with a workflow, I think it's good. Basically, all the work for the agent loop in the back is streamed to the stream.
You can open it in multiple windows. Even if you have a lot of stream IDs, you can use the latest stream ID to get it. That's what it looks like, but I think there will be only one stream ID when it's actually done in Temporal.
Yes, it's a chat window, or rather, it's one against the thread, so no matter which screen you open, multiple streams will not occur.
I think that's what it's going to be like.
It should be. In that sense, it's better to have one agent loop in the back.
I think it would be better to move them in parallel. I'm thinking about various things while looking at the implementation of Tempora. It's a bit of a delusion, so when you actually start implementing it, you'll probably be stuck with a lot of things you can't do. But I think that's about it for now.
I've been digging, but I thought that Barthel is great for making such a resumable stream properly. It was released 4 months ago, so I thought it was well done.
According to the use case, there are quite a lot of cookbooks that Barcell makes and AI SDK does this in this case. In that sense, it has progressed a lot. It makes me a little nervous when I think that I had to make this by myself.
It's like that. Well, I recommend a lot of things. Maybe at first, I thought I would do the console version simply with the UI stream.
We have a call.
I see, I see, I see. I wonder if it's okay to use it as a slack base. Or, I don't know, I think it's okay to do it on the Paclac web without having anything to do with slack.
That's right. Something like that.
I really want someone to fix this area. Itako-san is about to explode. I'd like to have three more Itako-sans.
Well, that's about it. Oh, I'm running out of time. Sorry. That's about it for today. Thank you very much.
Sorry about that. I didn't look at the time.
How is it going recently? Was the workflow until September?
I usually work as a workflow engineer, but so far I haven't done much.
If you have a solid knowledge of the workflow, you will definitely have a workflow around the future platforms, especially around agents. If you say, let's make a board for AI agent, or let's do something like this with a board, the workflow will definitely come in, so it's certainly good to be quite familiar with this part.
Yes, I did that. I entered the platform a few times and implemented light functions, such as workflow. It's not that long, so I think Mr. Shibutani is probably more familiar with the workflow.
I still don't understand the specifications of the functions. Like, this function is for this kind of thing, or this can do this, or that can do that. I don't understand the domains around the functions. I don't know why this is necessary, or why this function is so important.
I only know one side of it. There are functions like this, and this is important, and this is the core. I only know one side of it. I didn't really go deep into the product, like the platform. I can't make a proposal for the function. IZUMIN and YOSHIKI-SAN are included in that.
Yoshiki-san's platform-like approach seems to be the core of it, so in that sense, it's better. I've been doing a lot of tech-oriented stuff for a while, so... I think it's good, but I think it's better to be able to develop on the premise that there is a domain. I think it's possible to make something that has value all the time.
I think it's really good. When you're in a workflow, you get to connect to a variety of products, so you naturally become familiar with each product.
Well, I guess that's about it.
Well, that's true.
There is a depth to the domain. But what I think the most when I work as an agent is that it has become a concept that is close to human. In the future, when the field of engineering is to solve not the system logic, but the agent logic, What is important on the domain? What do we need to protect? We need to make it linguistic. So, what should we do? I think it's better for people with domain knowledge to do it. It's overwhelmingly strong, the agent development.
If you use LLM, you can do it very quickly, so this is really good, isn't it? There are probably infinite of them. So if you get familiar with the workflow, it's probably quite difficult to use this part of the function. I think it's good to be able to do this here. Well, that's about it.
Yeah, that's right.
Chatting is addictive, isn't it? I think it's quite expensive to make it into a language. What you want to do, you probably have to do what the screen remembers, and then click, click, click. In order for the agent to understand it, it would probably cost a lot of money to translate it into Japanese.
The more you get used to it, the more difficult it is to control. The cost of conversion.
That's right. For example, I think it depends on the system, what you want to do is already decided, for example, if you upload the file, it will do the rest for you. You can guess what you want to do. This is the file, right? Let's do this, and this, and this, and this. What do you think? If you say yes or no, I think it's still okay. If you ask me to do what I want to do in Japanese,
Well, there are many people who can't do it, right?
Yes. Once the contract is uploaded, the rest of the work is taken care of. In addition, once it is approved by the company, and they do it for you, even if you don't know about it, you don't have to worry about it. I got the contract, so I said I'd give it a try, and they did it all for me. They said, well, this application is necessary, and they did it for me.
It's definitely useful. I think it's important to know how to trigger an agent without using Japanese. There are a lot of options, like suggestions for agents. This is this, so this is this. There are a lot of things like that. I think you can use the scattered cases naturally at first.
If there is another one, it is a case where you can proceed with things based on notifications or notifications. You can do something laboriously in the chat here. If you ask me to explain what I want to do from scratch, it's going to be a lot of work. I'd like to fill in the context to some extent, from an agent, for example.
For example, if you use a credit card that you paid with, the agent who catches the credit card history says, this is the payment from yesterday, right? If you ask me if I'll do something like this, I'll just say yes, so that's probably easier to use.
I think it's true that you can't use it if you put it in chat. Recently, there have been more cases of assistants on the help page. I don't use it. I think it's probably better to use a normal keyword search.
My first name.
Mmm, that's right. That's right.
Recently, Google has started to respond to agent-like searches. When you search for something on Google, there is always a response from an agent.
Yes, yes, yes. That's how natural it is. I can see the results of the search, and the response summarized by the agent. It speculates what we are looking for and what we want to know, and then writes the answer.
Well, if you do something like a question, it comes in.
I think there is a speculation that this person wants to know something like this. It's not just a search result.
That's about it.
Well, that's about it. Well, everyone is trying to figure it out, so I thought I'd give it a try. I think it's a world with no answers. I think everyone should give it a try. I think it's great to have a sense of challenge. If you have such a sense of challenge, I think it's a chance to make a proposal like this.
It might be a good idea to search for answers that are not in the chat UI.
Yes, that's right. That's right. I think that's really true. Even in normal operations, I think the first thing that makes it simple is the easy-to-use input.
That's true.
Well, that's about it. If you do that in the workflow, you'll be able to touch around the agent and stuff. I wonder if it's okay because the range of technology in that area is also expanding.
I think we talked about this a little while ago, but in terms of enabling or platforming, we need to create a proper platform for the agent. That's what I saw. The concept of observability changes in the world of LLM. If it's just the observability of the system as before, it won't work.
I have to think about it. So I put this system in the corner of my head. Later, when I tried to observe it from a platform perspective, I was like, what is it that I need? It might be a good idea to think about it. It's a world where there is no answer at all. At the moment. In the world. Well, it's like Langfuse. It's just like that.
There are more and more ways to observe, but I don't think it's enough for the actual use case.
Yeah. Oh, there was a comparison test. Comparison of models. Recently, models have become smarter. It's more important to give what kind of information than to mess around with the prompt.
If you provide proper information, LLM will work properly.
That's how it really is.
It's difficult, isn't it?
I see. Also, inputting and outputting can't be predicted, so it's hard to simply numericalize. There are several approaches to numericalization. For example, to determine if it fits into this context, we use LLM. I'd like to think about how it should be, as a platform. Also, if I die in LA, the service will probably stop.
I see. There seems to be a lot of things that don't move when you fall back. The accuracy is not enough, so something completely different comes out. It's like the GPT-OSS that AI put out. I feel like I have to think about it, including those things, as a platform.
Well, that's about it. It's not like I'm stopping you or anything, but that's about it.
Okay, let's continue. I think it's getting more and more like a platform. It's getting more and more like a platform. I'm sure it will make you feel better, so please let me know as soon as possible. I need you to tell me that I can focus on that soon.
If you do it in 7A, you can do anything, but there are a lot of cases where you don't have enough people for the product. If you do it in 7A, you won't be able to get out of it. Well, I think it would be good if that area could be included, so let's continue to exchange information there.
Thank you very much.