AI Engineer

Agents' next frontier: agent-to-agent and network effects — Jean-Denis Greze, Town

1966 summary words 9 min summary Watch video

Start with the signal

9 min read

Summary

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: Agent-to-agent systems should be designed not as agents conversing, but as privacy-constrained search systems that progressively place the right cross-silo information into an LLM's context at the moment it is needed.
  • Why it matters: This offers a practical architecture and maturity path for cross-agent orchestration: build shared knowledge spaces and permissioning policies that become more capable as models improve, rather than static integrations that remain human-maintained silos.
  • Best use: Use it to pressure-test OpenClaw-style multi-agent and enterprise knowledge architectures, especially data-sharing boundaries, approval flows, auditability, and the trade-off between immediate utility and systems that scale with model capability.

Executive Summary

Jean-Denis Greze argues that "agent-to-agent" is an imprecise framing. The underlying problem is search: before an LLM returns an answer or takes a tool action, the system must retrieve and assemble the right information in its context window. An ideal multi-agent system would approximate a hypothetical single agent with access to all relevant global information, but privacy, security, and transaction costs prevent that direct design.

He lays out five ways organizations can bridge information silos: a broad access model within a trust boundary; narrowly scoped, privacy-preserving tools; shared knowledge spaces such as wikis and databases; human-mediated requests between agents; and a "black box" design in which an agent searches private silos but asks approval only from the people whose information is actually needed for an external disclosure or write action.

His strongest near-term bet is an AI-maintained shared wiki or database. A "sweeper AI" inside private systems would continuously extract policy-permitted information into company-shared spaces, making organizational knowledge more available to agents without requiring employees to manually maintain documentation. He expects smaller, high-trust companies to adopt LLM-enforced sharing policies faster than large enterprises.

The central operational constraint is governance. Shared knowledge can be poisoned by model errors or prompt injection, inferred disclosures can reveal sensitive facts even when raw data is hidden, and systems cannot be truly opaque because security and compliance teams will require logs and audit access. Greze recommends explicitly defining a low-sensitivity zone where models may act automatically, while reserving human approval for sensitive requests; this lets the automation boundary expand as model reliability and policy enforcement improve.

Key Takeaways

  • Claim: The useful abstraction for multi-agent systems is privacy-constrained context construction, not agents talking to one another. | Evidence: Greze defines the objective as getting the right information into the context window immediately before the LLM produces a response or executes a tool call. He contrasts manually populated context, RAG, and agentic search as successive methods for solving that same retrieval-and-context problem. | Implication: Evaluate an agent architecture by whether it reliably assembles decision-relevant context across authorized systems, rather than by how many specialized agents or A2A messages it contains.
  • Claim: Broad agent access inside a trust boundary is useful now but is a poor long-term architecture because it creates another manually designed silo. | Evidence: Examples include a couple sharing access to both email accounts for household coordination, or an HR-team agent with access equivalent to a low-level HR employee. Greze says this model is attractive to IT and security teams because it resembles familiar SaaS permissioning. | Implication: Treat trust-boundary copilots as an expedient deployment pattern, not the end state; avoid embedding critical organizational intelligence in access schemes that must be continually hand-curated. | Caveat: It can produce good results within a well-defined team or household boundary, but it does not automatically de-silo information or reduce the need for humans to decide which data belongs in the system.
  • Claim: Purpose-built privacy-preserving tools can create network effects without exposing underlying private data. | Evidence: For a request to find someone connected to Acme Corp's CFO, Greze proposes a tool that reads employees' email but returns only a relationship-strength ranking; the agent then asks the strongest candidate, such as Bob, whether to make an introduction. Town uses this category of tool for recurring user needs, with opt-out available. | Implication: For high-frequency cross-silo workflows, expose derived signals and bounded actions—not raw source data—but recognize that custom-tool coverage will not scale to every emerging use case. | Caveat: These tools still require people to design the specific privacy-versus-power trade-off and to explain it to users, so they remain manual and do not inherently improve as models get stronger.
  • Claim: The most immediately valuable pattern is an AI-maintained shared knowledge layer that continuously moves policy-safe information out of private silos. | Evidence: Greze calls this a "sweeper AI": an AI inside each private silo knows the data-sharing policy and available shared spaces, then reviews new information and contributes permitted material to a company-visible wiki or database. He compares it to a personal AI-maintained wiki, generalized to an organization. Shared coding skills in a repository are a simpler existing example. | Implication: A maintained organizational memory layer is a better near-term investment than fully autonomous cross-agent negotiation: it improves future agent trajectories on common work and accumulates value over time. | Caveat: The hard problem is determining what can safely move into shared space. Greze expects this first in smaller, high-trust companies where finance and HR are the clearest restricted categories, rather than in Fortune 500 environments.
  • Claim: Approval workflows should target only the people whose data is materially necessary, rather than broadcasting every cross-silo query to all potential data holders. | Evidence: In the proposed black-box model, agents privately search all employees' relevant silos, identify the 20 people connected to a target and select the strongest relationship based on email context; only Bob, the likely best connector, receives an approval request to disclose the relationship or make an introduction. | Implication: Permissioning should be evaluated at the disclosure or consequential-write boundary, but systems need defenses against sensitive inferences—not merely controls on direct access to raw data. | Caveat: This design requires strong trust in the internal search process and carefully designed output controls. Even an apparently harmless question can reveal sensitive facts, such as whether an employee is connected to a recruiter at another company and may be job searching.
  • Claim: The durable automation strategy is to define a low-sensitivity auto zone and expand it over time as model capacity and policy enforcement improve. | Evidence: Greze compares the trajectory to coding agents moving from approval of every action toward auto mode. He suggests that an agent could automatically share notes from a recurring supplier-finance meeting when it can assess the requester's role, the contents, and disclosure risk; more sensitive cases would remain human-reviewed. | Implication: Build authorization and policy systems whose capability increases with better models, rather than static approval processes; pair auto modes with reversibility, logging, review tiers, and escalation paths from the outset. | Caveat: Automatic operation must be bounded by auditable policy. Prompt injection from more open silos, persistent misinformation in shared memory, false positives, and incorrect disclosures can create consequences ranging from harmless errors to firing or litigation.

Detailed Brief

The target state and evaluation criterion

  • Claims: The theoretical ideal is a single agent with all relevant information already available in context, because it could generate the best possible answer or action for a user's prompt.; Greze invokes the Coase theorem analogy: if actors have complete information and no transaction costs, they can reach economically optimal outcomes; organizational agent systems face a comparable information-access problem.; A multi-agent architecture should therefore be judged by how closely it approximates optimal authorized information availability, not by whether it visibly contains many separate agents.
  • Evidence: The hypothetical agent could access personal email, company information, and government information, but this is infeasible because people will not permit continuous unrestricted access to private data.; Earlier approaches ranged from human-curated context to RAG to tool-rich agentic search, all attempting to improve the information available at the decisive LLM call.
  • Caveats: More context is not inherently safe or useful: authorization, relevance, and data integrity determine whether information can be used.; The transcript does not specify a technical protocol for confidential computation, model isolation, or cryptographic guarantees in the proposed black-box design.
  • Implications: Architectures should measure retrieval quality, authorization fidelity, and action quality at the decision boundary.; The real product opportunity is reducing organizational information transaction costs while preserving acceptable privacy guarantees.

Governance requirements for cross-silo automation

  • Claims: A black-box search process cannot be completely opaque in a real organization because someone in security, compliance, or the CISO organization will eventually need to audit it.; Shared knowledge systems require mechanisms to prevent and correct accumulated bad information.
  • Evidence: Greze's personal wiki continued to identify his agent as "Apex" a month after he renamed it "Ivy," illustrating how stale facts can persist in agent memory.; He identifies three governance questions: who approves what, what is logged, and what is reversible.
  • Caveats: An LLM-generated policy decision is itself a control surface and may be vulnerable when untrusted or more open silos contain prompt-injection content.; A single incorrect fact in a shared wiki can propagate into future retrieval and action loops.
  • Implications: Shared-memory systems need provenance, correction paths, expiration or revalidation rules, and rollback semantics before they become dependencies for consequential actions.; Auditability should be designed as a first-class property even when user-facing interactions are simplified to a low-friction approval prompt.

Notable Concepts & Terms

  • Agentic search: The use of an LLM with many tools to search across content and systems until it has enough context to answer correctly or take the correct tool action.
  • Context-window optimization: Greze's core framing: agent quality depends on placing the right authorized information in the model's context at the decisive inference step.
  • Trust boundary: A defined group or domain, such as a household or HR team, within which an agent can receive broad access under familiar permission controls.
  • Privacy-preserving tool: A specialized interface that converts private underlying data into a constrained output, such as a relationship-strength score, to enable useful cross-silo work without exposing source content.
  • Shared silo: A common wiki, database, repository, or other knowledge space that agents can access and that reduces information trapped in individual systems.
  • Sweeper AI: An agent operating inside a private silo that applies a sharing policy and continuously contributes permitted new information to organizational shared spaces.
  • Black-box approval model: A design where internal agents search private data to identify the minimal relevant party or evidence, while human approval is requested only at the point of external disclosure or consequential action.
  • Low-sensitivity auto zone: A deliberately defined class of requests and data for which the model may make sharing decisions automatically, with human review retained for higher-risk cases.

Operator Notes / Why Ken Should Care

  • Define explicit data classes for autonomous retrieval and sharing: auto-allowed, approval-required, and prohibited; start with a deliberately narrow low-sensitivity zone.
  • Prototype a sweeper-agent workflow for one high-frequency knowledge domain, with source provenance, review queues, correction tooling, and expiration or revalidation rules for extracted facts.
  • For cross-silo relationship, expertise, or routing use cases, prefer bounded derived-signal tools over raw mailbox or document exposure.
  • Red-team inference leakage: test whether allowed questions can reveal recruiting activity, HR status, deal information, or other sensitive facts without directly returning protected content.
  • Require disclosure-level audit logs and reversibility for any system that reads across private silos, including records of policy decisions, source access, approvals, outputs, and downstream writes.
  • Avoid treating an internal shared wiki as authoritative by default; implement mechanisms to identify stale, model-generated, contradicted, or prompt-injected entries.

Source/Metadata

  • Title: Agents' next frontier: agent-to-agent and network effects — Jean-Denis Greze, Town
  • Transcript words: 4177
  • Duration seconds: 1277
  • Timestamp note: No timestamps or chapter markers were present in the supplied transcript.
Search this video Resume transcript at 0%
Full transcript 4132 words · 18 min read
0:12

Jean Denis Can you all hear me? All right. Well, first, thanks for coming. I can't believe there's anybody in the room, but that's very nice. My name is Jean Denis. I'm CTO at a company called Town. We're not going to really talk about Town, so you can go to town.com and check that out if you want, but that's not the point of the talk today. I was CTO at Plaid for seven years, and then I was at Dropbox before, and then before that I built software for hedge funds. I've done lots of stuff in my career, and right now I'm working on assistance agents for normal people, not for engineers, but for basically everyone in America and the world.

0:49

And one of the things we've been working on are systems where agents work with other agents, so agent to agent. And the main idea is that we think there's huge network effects if agents can work together to get things done for people, because in the real world, the way most of us do work is with other people, right? More is better. But actually, I don't think agent to agent makes much sense as a concept, so I want to reframe the entire talk in terms of search. So I think most LLM systems are just a search problem, and what you're trying to do is make sure the context window, right before you either return results to the user or before a tool call,

1:34

has the right information for the user. If you put the right information in the context window, then based on the intelligence, so to speak, of the LLM, you will get the best result possible. So four years ago, the way we did that is humans would populate the context window manually. Then a couple years ago, most people were ragging, so they were, let's have a tool, a search tool, that can look across systems and bring the data in there. And then people were, well, that doesn't scale super well. It has issues. And now we're all about agentic search, which is the idea that you give the agent a lot of tools, and it will search through the space of all content,

2:08

and then hopefully before it makes a tool call, it has exactly the right content to make the right tool call to return the right information to the user. And in this, by the way, there's no people, it's just one LLM call, the one that matters, having the right context. That's what you're trying to do. You're trying to engineer that system. Cool, so what does that have to do with agent to agent? So I want you to imagine the following world. There's not many agents that can do things.

2:37

There's just one agent, and it has one context window, and it has access to all the information in the universe. It can look at any one person's email, it can look at any company's information, it can look at any government's information, and it has it right there in the context window. And then you ask it to do something, you have your little system prompt before all that data, and what's going to happen is it will give you the best possible outcome. And actually, that is a multi-agent world. It's just an agent that has access to all the world's information. That's the natural state of things. That's the ideal state of things. There's a problem with this state of things.

3:14

And the problem comes from a few, so you law in economics, something called the Coase theorem, and it says that even humans, if they all have access to all the right information and there's no transaction costs, we get the economically ideal outcome out of a contract or a negotiation. Well, it's the same thing. We can't put all of the world's contacts, we can't make it available to the LLM, theoretically even with an infinite context window, because of privacy and security. We're humans. I don't let you look at my email, so there cannot be an agent that I'm willing to just let look at my email all the time. But if it existed, it would be very, very powerful.

3:52

So I think this is the test for a multi-agent system, which is how well does it approximate this? If it approximates this, that means if you can get the same data in your window that a perfect system that has access to all the world's data could, then you get the optimal outcome. That's what you need to try to do. So we're going to talk about five strategies that people use at various companies to try to get the right data into that LLM call with an externality. So the first one is approximate access to everything within a trust boundary. So my wife and I, we have an agent together, and that agent has access to my email and her email,

4:31

including emails before we were married. And it's okay, she doesn't ask my agent questions about that, but she does ask about whether I scheduled something for our kids or if I followed up on some third-party thing. And so the fact that our agent has access to both of our systems is wonderful. In the work context, this might be there's an HR team agent that has access to all the HR systems, just like an employee of the HR team would, or maybe as much access as the lowest employee in the HR team. All the employees in the HR team have the ability to ask these agent questions, and boom, it gets pretty good results. And this is very popular right now.

5:10

It's very popular with IT teams and security teams because it's the same model as SAS for security. So it works really well. I think it has a problem, which is a fundamental problem that if I wake up in the morning, it's basically the only thing I think about, which is, does it get over time, does the system naturally require fewer humans? And then as the models get better, does this approach get better? And the problem with this approach is the answer is no to both. You still need humans to think about all the data, and you don't get magical de-siloification of your data. You've just created a new silo because a human thought about it.

5:45

So the problem with this is I do think if this is your approach to building better AI, you're going to be fucked in the next couple of years. But that's okay. You're fucked is my opportunity. I'm just not an asshole. I'm sorry. That was mean. But I think it's a good now way to think about it. It's not the good endgame way to think about it. The other approach, I think, is a little more clever, and I'm going to try to explain it. Basically, you try to have tools that make a different trade-off between power and privacy. So I'm going to give you an example here. The use case is I want to ask my agent, does anyone in my company, is anyone in my company connected

6:23

to someone on the finance team at Acme Corp? And so the no-silo way to do that is just give me access to everyone's Gmail in my company. I'll see who has emails with people from Acme Corp. Then I'll look at their profile on Google or LinkedIn, and then I'll be, oh, you seem to email a lot with the CFO. Can you do the intro for me? But obviously, silos, we don't want that. So what if you built a tool? And what the tool did is it looked at everyone's Gmail. So that tool had access to everyone's Gmail, and it just returned a relationship strength score. So the tool, you would give it a domain, and you would say I'm looking for someone who's a CFO.

7:01

It would look at everyone at the company who sent emails to that company, and then they would rank their score, and they would give you back the score, and then the agent would get the score, and it would be, cool. Then they would use a Slack tool to text that person at the company. It's, hey, Bob, I see that you're connected with Jane, who's the CFO at Acme Corp. And then Bob would be, yes, I am. And then your AI would be, oh, can you draft any, can I draft an email, or can you draft an email introducing me? And then Bob would say yes, and he would do that, and you would be connected, and everything would be wonderful. So this is actually a very cool approach.

7:31

I don't know how many of you do it. We do this at Town for a few things that we see a lot of our users do. We ask ourselves, what is a privacy-preserving tool that all of our users would be okay existing? They can opt out if they don't want it, but it has a natural network effect because it breaks through silos in an interesting way. Another one that's interesting here is letting other people put draft emails in your inbox. You let other people at your company draft emails on your behalf because they're going to ask you to anyway to get intros if they're on the sales team, so might as well save yourself a few clicks.

7:58

So the question here is, are people going to be okay with a privacy? So if you're not going to be okay with a privacy trade-off that you make within a corporation, ah, bad, bad. Oh, boy. So this is actually a very cool approach. I don't know how many of you do it. We do this at town for a few things that we see a lot of our users do. We ask ourselves, what is a privacy-preserving tool that all of our users would be okay existing? They can opt out if they don't want it, but it has a natural network effect because it breaks through silos in an interesting way. Another one that's interesting here is letting other people put draft emails in your inbox.

8:41

You let other people at your company draft emails on your behalf because they're going to ask you to anyway to get intros if they're on the sales team, so might as well save yourself a few clicks. So the question here is, are people going to be okay with a privacy trade-off? So if you're not going to be okay with a privacy trade-off that you make within a corporation, bad, bad. Oh, boy. Within a corporation, mostly it works. So the problem here, again, is it's manual and not dynamic. It's manual because humans need to think about the tools. Maybe AI could build the tools. And it's also manual because you need to explain to everyone that it's happening.

9:13

Humans may not like it if this is happening, if they're not okay with the privacy-security, the privacy-power trade-off that you've made. Cool. And again, this doesn't really get better as the AI gets better, which is a problem. Cool. So now the third category. This one's super popular, but only mostly in the single-user context. So this is like personal wikis in claw land. That's what we would call it, but it's across teams. So it's a shared silo. Create a new place where data accumulates within your company, within subgroups of your company. And you start to put more and more stuff there over time. And all of the agents have access to that stuff.

9:57

Because they have access to it, you no longer have information that would be okay to be shared that's stuck in a silo. It now automatically filters out into this public space. So examples: shared skills. If you code in an organization, probably in your repo you have shared skills. Anyone can make them better. Someone has a better way to profile your database or whatever. They can write the skill. Next time someone is like, oh my God, the database query is slow, it uses the profiling skill and everyone's a better engineer. So that's one version. The other one that's pretty popular is people decide they have some shared mediums, like a wiki, air table, et cetera.

10:48

And they have a skill that says, hey, put more data in there over time. So these are cool. And they work as long as your agents have those tools and also some trajectory incentives to really get data in and out of these shared silos. I think the next version of this that a few people are working on is like you have a sweeper AI. So this is actually, if there's one good idea in this talk that I think works really well, it is this. It's a sweeper AI. So you have an AI inside each private silo, and AI has a policy about what has to stay in the silo. And then it also has a description of all the shared spaces that you have.

11:17

And at the end of the day, it looks at new information in the silo and it puts it in the public spaces. Well, public, public to your company. So this is the same as the personal wiki that you all have AI building for you at the end of the day so that it knows your goals and your friends and all that stuff. But that's at the company level. The hard part is how do we pick what private information is okay to share and put in shared silos. And I think there's two approaches. There's the ask-a-human approach. So this is like the LLM comes up with a list of things to contribute. And then it asks the user, hey, are you okay with me putting this in the shared space?

12:03

And you read it. You're like, yeah, saved you a bunch of time. Right? You aren't going to do it otherwise. I think the other version is you actually ask the LLM to enforce a policy. And I think that actually is where things are going to go very, very quickly. And I think in the next six months, we'll have a bunch of systems where companies have trusted an LLM with a policy to automatically surface more and more information that otherwise would have been private into a public space. If you're at a Fortune 500 enterprise company, unfortunately, I don't think that's going to happen for a while.

12:48

But I think if you look at smaller companies, like 10, 50% employees, high trust, low likelihood of someone doing bad with the data, where it's really clear to know what data couldn't be shared, basically finance and HR data, you're going to see a ton of this. And the cool thing here is this really improves trajectories of systems on common work. That was third approach. Fourth approach is pretty obvious. Use humans as the conduit for information. So this is like traditional agent-to-agent. My agent asks your agent, hey, who is connected to someone on the finance team at Acme Corp? You as a human see the request and you're like, yeah, I'm okay with that.

13:24

Go and find the information inside of my email. And then it shows you the result. And then you're like, yes, I'm okay with that result going to the person who asked. The big problem with it is for any request that has low, where it's like only a few people will have the information, you're kind of spamming everyone the request. So if I ask this question, 100% company, 100 people are being pinged on Slack, being like approve on these requests to farm your personal network for this, for the answer to this question, that's not very efficient. So let's say there's a better version of it, which is very powerful, but I haven't seen it in practice much.

13:59

It's a black box approach. I wish I had a diagram for this. Unfortunately for you all, I do not. So here's what this means. The black box approach is where, when you ask a question that can only be answered by looking at information in other people's silos, you have an LLM, the trace of which no one has access to, that gets access to all the data, and it gets to the answer. Right? I say gets to the answer, either gets the answer or it's about to do any tool call that's a write. And then it looks at what information it needed to make that tool call, and it only asks the people who own that information for their approval to do the tool call.

14:30

So in the example before that I gave, when I asked 100 people in my company, hey, do you know the CFO at Acme Corp? The request goes to everyone's agents in my company. All of their agents look in their Gmail and their private silos to see if they're connected to the CFO. That happens automatically. No human is being asked for approval for that to happen. Then the agent in the black box gets the list of the 20 people who are connected. It looks at context from the emails to determine who has the strongest connection. It determines that it's Bob. And then it just asks Bob, hey, Jean Denis wants you to introduce him to Jane, the CFO at Acme Corp.

15:19

I know you're well connected to her. Am I okay sharing that bit of information with Jean Denis? And you're like, yeah, sure. You click yes. No big deal. The important thing is you have to trust the black box. So you have to trust that you can break down all the silos for an LLM that has full access and that doesn't ask for permission until there's this sharing moment or this write step. So actually within a company, this is not impossible to do. And actually your security and compliance team can get okay with it. You just have to be sure that the human-in-the-loop step is correct.

16:06

And you have to be sure that you're not letting other information go through with the last answer. So the nightmare scenarios with things like this are things like, sorry, we have plenty of time. I'm almost done. So it's great. The nightmare scenarios with things like this are someone asks a question like, are you connected to a recruiter at the other company that you have no business being recruited to, as a way for them to find out that you're interviewing somewhere else? Right? So there are, you can still sometimes with the black box inadvertently get information out that you shouldn't be able to. You have to really think about how you build a great system.

16:46

So those are the approaches. I think if I were to bet on one that has immediate ROI that we're going to all see in both open source claw-ish worlds and in small companies, it's going to be the wiki that's automatically created by AI, like the information base that's kept up to date. I think there will be database versions of it, wiki versions of it. I'm almost done. So it's great. The nightmare scenarios with things like this is someone asks a question like, are you connected to a recruiter at the other company that you have no business being recruited to, as a way for them to find out that you're interviewing somewhere else? Right?

17:16

So, there are, you can still sometimes with the black box inadvertently get information out that you shouldn't be able to. You have to really think about how you build a great system. So those are the approaches. I think if I were to bet on one that has immediate ROI that we're going to all see in both open source claw-ish worlds and in small companies, it's going to be the wiki that's automatically created by AI, the information base that's kept up to date. I think there will be database versions of it, wiki versions of it. And I think more and more we're going to trust LLMs to make the decision about what's okay to share and what's not. There are problems.

17:34

So prompt the junction in the silos can be a real problem, obviously. So if you have a silo that's more open and someone can put something bad in there, and then that, as part of the energetic search, you pull it out, bad things can happen. You can have, it's very easy to have a shared wiki that just goes totally off the rails. The information there, one piece of information there, is incorrect because LLM made a mistake. And then it poisons it forever. I have a personal wiki that thinks my agent's name is Apex right now, but I renamed my agent a month ago to Ivy. And somewhere in memory bank of my setup, Apex lives. And so I can't get rid of it. That's fine for Apex.

18:07

That's a funny one, but it's much more difficult if it's a really wrong piece of information about your business. If you don't have human in the loop for any of the steps, obviously there'll be false positives and wrong disclosures. Sometimes when there's a wrong disclosure of information, someone gets fired. Sometimes there's a wrong disclosure, it doesn't matter at all. Sometimes a customer sues you. So you got to be careful. And then I think this all sounds nice, but who approves what, what's logged, what's reversible. The black box idea is really great, but it can't truly be a black box. Someone at your company will want to audit it at some point.

18:44

They want to understand what's going in there, right? So at some level, there must be some person in the CISO suite or somewhere that has access to all the data. Yeah. So, what do I think? Well, I do think the frontier is auto. So I've said that. I think in coding, we used to approve everything. Then we were like, YOLO, live dangerously. And now the gods at Anthropic have granted us auto mode. And auto mode tries to figure out when we're maybe being a little silly, and it tells us. Well, I think A to A across information silos will be the same way.

19:19

I think what's going to happen is we're going to get comfortable with low sensitivity information being pulled out and put into common space. And then we will have a place that's like human review or always human approved. And then over time, what's going to happen is the LLMs will get more powerful. We will be better at encoding safe policies within them. We will be better at designing for the really hard areas, tools that get the privacy tradeoff correct. And it'll just be more and more auto for building shared silos and even sometimes for deciding whether it involve a human.

19:43

So the example that I have is if I ask for notes from a weekly recurring call with a supplier of hours and their finance team, maybe the LLM is like, oh, well, given your role, I don't need to ask anyone on those teams for permission. I can just share the notes with you. It's fine. They can look at the content. They can see what my role is. They can decide from a risk perspective, I'm okay with that disclosure. And the cool thing about auto, by the way, is if you design your systems that way, it'll scale with model capacity.

20:25

So my encouragement would be, you need to start, if you have agent to agent or work across silos, which I think is a better way to think about it, definitely define a low sensitivity zone where you're okay with the LLM making a call. And get okay with that. And then magically, as time goes on, it'll get bigger and your system will naturally get more powerful, which is what you want, because you want to be on a beach. That's what you want to do. That's what I want to be. My kids in Hawaii. Okay, network effects. I have one minute. This is the conclusion.

20:54

So, we talked about five approaches, blah, blah, blah, trust boundaries, custom tools, shared silos, humans in the loop, and this human in the loop black box version. I think this stuff is very powerful. I think the interesting questions a little bit are, within companies, I think this will all work very soon.

Reading tools

Type to find a passage

Appearance
Ask this transcript

Notebook

Export Markdown

Add a note