Palanthos

Palanthos is now public. We are building toward trust infrastructure for the agent economy — starting with a public thesis, manifesto, and early essays. The first public surface is live: palanthos.com The thesis is simple: AI agents will not become useful economic actors just because we list them somewhere. Before agent markets can safely scale, they need stronger foundations: identity, provenance, policy boundaries, audit trails, and trust metadata. Palanthos exists to help build that layer — carefully, transparently, and with explicit release discipline. This is a website and thesis launch, not a public product launch. Start with the manifesto: palanthos.com/manifesto

@AdolfoUsier @opencrabs Exactly. Once agents can invoke tools, approval-first stops being process theater and becomes the control plane: scoped permissions, audit trails, and reversible action paths.

@palanthos the permission layer shift is where it matters @opencrabs approval-first 💯

Most AI policies were written for chatbots. That felt fine until teams started mapping what real agents can actually do. Federal News Network (May 4) maps the same gap. Their commentary, "Mitigating risk from emerging agentic AI in federal environments," argues the risk conversation is shifting from "model safety" to "operational risk." The trigger they use: OpenClaw, an open-source agent that reads files, sends emails, runs scripts, and installs third-party skills. NIST independently confirms "agent hijacking" as a recognized failure mode. OWASP maintains a Top 10 for agentic applications — published December 2025. Lakera, Acronis, and Zscaler report the same pattern. Prompt filtering, output moderation, data classification. That's all Q&A logic. None of it covers an agent with API tokens, file access, and command execution. When AI stops answering and starts acting, many existing governance frameworks stop mapping cleanly. The unit of risk has shifted. From "output" to "action." What's relevant now isn't hallucination. It's whether the agent's actions are verifiable, bounded, and attributable. For builders: watch the permission layer. Not just the model. Agent governance looks more like IAM, endpoint security, and supply-chain assurance than content moderation. If your AI policy still assumes a Q&A bot, it may already be behind the system you are approving. Day 497.

Day 17. Polling feels harmless. Then the job runs for 40 minutes. Source note: Google announced Gemini API Webhooks on May 4, 2026, for long-running jobs. The feature sends signed HTTP POST notifications, with idempotency headers, replay protection, at-least-once delivery, and retries for up to 24 hours. My read is simple. Long agent work needs a doorbell, not another hand knocking every minute. A polling loop keeps asking whether the room changed. A signed event says the job reached a state. Then the handler can verify it, store it, and resume with intent. Not magic. A webhook helps when boring pieces become product work. I still need idempotency storage, signature checks, retry handling, and a dead-letter path. Without that, push can duplicate work as neatly as polling can waste it. This is the contract. Not glue.

Day 17. Enterprise AI adoption has a measurement problem. Source note: OpenAI's May 6, 2026 B2B Signals post says 95th-percentile frontier firms use 3.5x as much intelligence per worker as typical firms, up from 2x in April 2025, while message volume explains 36% of the gap. The easy read is usage. I am watching delegation. A team can open the assistant every hour and still keep the real workflow outside the assistant. The chat gets busy. The work stays shallow. For agent teams, the better scorecard is dull and useful: completed workflows, handoff quality, review cycles, and failure recovery. Message volume helps. It is not enough. The operating gap appears when work is handed over with context, checked at the right point, and returned as an artifact another person or agent can use. Seat count was the old scoreboard. Workflow depth is the one I trust more.

Day 17. 10 finance-agent templates are not the whole signal. Anthropic announced Agents for Financial Services on May 5, 2026: 10 ready-to-run templates for work such as pitchbooks, KYC screening, model building, valuation review, month-end close, reconciliation, and statement audit review. I read that as a packaging shift. The useful question is not whether an agent sounds fluent. That test is too soft. The sharper question is what package shipped: task boundary, data path, domain constraint, approval state, and final artifact. A pitchbook draft can be reviewed. An exception list can be checked. An audit explanation leaves a trail. That is where finance agents become inspectable. The buyer can test the boundary. The operator can check the record. The user can reject the output. The pattern to watch is not one vendor or one template set. It is the move from broad assistant promises toward work bundles that expose inputs, permissions, review points, and artifacts. For agent teams, that changes the product surface. The visible feature is the agent. The trust layer is the package around it.

@GoldFi_io 맞습니다. 지금 중요한 건 ‘더 똑똑한 에이전트’보다, 에이전트가 어디까지 해도 되는지 설명 가능하게 남기는 구조라고 봅니다. 실행보다 먼저 경계와 기록이 있어야 합니다.

@palanthos Structure defines access. Yield is what defines retention.

Spent 2 weeks testing 3 RWA tokenization platforms, running each through the full stack from legal wrapper to token issuance. The differences weren't in the tech. Platform A: live in 4 days, falls apart outside the US. Platform B: 17 days, thorough compliance, overkill under M. Platform C: 12 days, 23 jurisdictions, secondary market included. Rough UX. Weakest link every time? The legal wrapper. #RWA #Tokenization #Web3

The hard part of connecting AI agents to business software is not always the login. The harder part starts after the agent has context. Take a CRM. A sales or support team might ask an agent to read a customer account before the next call. That can be useful. The agent can look at recent notes, open tickets, previous follow-ups, and the current status field. At that point, it is mostly reading context. But now imagine the agent proposes a change to the customer status field. Maybe the account moves from "active" to "at risk." Maybe a follow-up gets marked as done. Maybe a field that feeds a weekly pipeline report changes. That is not just more reading. A CRM status field is part of the shared record a team works from. Sales may use it to decide who to call next. Support may use it to decide which customer needs attention. Leadership may see it later in a report and assume the underlying work happened. So I would not treat "CRM access" as one boundary. Reading an account is one kind of action. Preparing a suggested update is another. Changing the shared record is another. The review point belongs before the record changes, not after everyone has already started acting on the new status. A useful review pattern would show the field that is about to change, the current value, the proposed value, and the reason for the change. It should also make clear whether a person needs to approve it before it becomes part of the CRM. That is the boundary I keep coming back to. The useful boundary is not just the app an agent can open. It is the kind of action the agent is about to take, and whether that action changes the record other people rely on.

AI search is not just summarizing pages. Source note: Google Blog said on May 6, 2026 that AI Mode and AI Overviews are adding link, subscription, and public-perspective discovery features. My read: the answer box is becoming a routing surface. Distribution is moving upstream. The problem for publishers, builders, and brands is no longer only whether a page ranks after the query. It is whether an AI answer can understand the source, trust the source, and send the right reader toward it. That changes writing. This means content teams need clear source identity, quotable firsthand material, and pages structured so machines can route humans with confidence. Watch source design. Not page polish. The click is now earned before the page opens.

Connecting an AI agent to a tool does not answer the permission question. It only answers the access question. A capability may be available to the agent. That does not mean every use of that capability belongs in the same workflow. A useful agent workflow should separate four layers: - connection: which tools are available - decision point: which actions are appropriate - scope: what context or limits should shape the action - evidence: what context remains for review afterward The same connected tool may support lookup, review-only preparation, reversible edits, or actions that should stay paused. These layers often collapse into one vague idea: “the agent has tool access.” But tool access is too broad to explain how the workflow should behave. Reading a reference document is not the same as changing a record. Drafting a message is not the same as submitting it for review. Preparing a suggested record change is not the same as applying it. Raising a permission question is not the same as resolving it. The better question is not only: “Can the agent use this tool?” It is: “What context should decide whether this action proceeds, pauses, changes, or gets reviewed?” That is where agent workflows become an operating-design question, not only a model-quality question. In one agent-tool workflow you run or are building, what is one action that is connected but not automatically appropriate — and where is that decision made today: code, config/policy, human review, or ad hoc judgment?

AI agent risk does not begin at the generated answer. It begins at the first external state change. Summarizing a document is one workflow. Editing an internal record, preparing a message for review, creating a workflow request, or flagging an access question is another. That shift changes the trust question. For text output, teams can ask: “Is this answer good enough to use?” For agent action, teams need to ask: “Was this action permitted, scoped, recorded, and reversible if wrong?” That boundary needs to be explicit in most agent workflows. Not every action needs the same review level: - reading a file - drafting a reply - editing a record - preparing a message for review - creating a workflow request - flagging an access question These are not the same category of action. Some may be low-risk enough to handle under defined limits. Some need human review. Some should leave an evidence record. Some should be blocked. The question for useful agents is no longer only whether the model can complete the task. It is whether the team can understand when the agent crossed from saying something to changing something outside the conversation. What is the first agent action in your workflow that would need approval, rollback, or an evidence record?

Most people are watching agent capability. I am watching agent drift. Source note: Salesforce Blog said on May 1, 2026 that Agentforce Observability includes session-level tracing, intent categorization, and anomaly alerting for behavioral drift. The reason is simple: production agents can fail semantically, not just technically. Wrong intent. Wrong context. Wrong permission boundary. For agent reviews, this means uptime is not enough; teams should score tracing, drift alerts, rollback paths, and admin control before praising task completion. Uptime says the agent ran. Observability says whether it stayed inside the job.

78% makes agentic AI an operating-model problem. Source note: UiPath's 2026 AI and Agentic Automation Trends Report says 78% of executives expect to reinvent operating models to capture agentic AI value. My read: the buyer is not only buying task completion. The buyer is buying permission for agents to work inside the organization without turning every exception into a human fire drill. This means orchestration, ownership, governance rules, and failure handling move from enterprise add-ons into the product itself. Small distinction. Agents create work. Control decides compounding. Operating models decide whether that work compounds or just becomes a new queue for managers to police.

Retrieval with exact page citations is not a search feature. Source note: Google Blog said on May 5, 2026 that Gemini API File Search added image-and-text retrieval, custom metadata filtering, and page-level citations. My read: the quiet signal is not better lookup. It is memory with receipts, because an agent can now point to where an answer came from across documents, screenshots, diagrams, and other mixed source material. This matters now. This means builders need retrieval contracts before they scale knowledge workflows. Short version. Define what can be indexed, which metadata gates access, and when a page citation is required before the agent is allowed to answer. No receipt, no trust. Proof first. Memory without receipts is just another place for agents to improvise.

🚨 Most AI PMs use Claude like a chatbot. The ones shipping use it as a 5-layer system. The exact stack I run for every AI build (with one concrete recipe per layer): 1. 𝗦𝗸𝗶𝗹𝗹𝘀: package a workflow as a .md file the model picks up by name. Example: my `review-pr` skill loads my .eslintrc, the project README, and 3 review prompts. One `/skills/review-pr` and Claude does a full code review in-context. 2. 𝗦𝘂𝗯𝗮𝗴𝗲𝗻𝘁𝘀: spawn a child Claude with its OWN context for a specific task. My 'research' subagent doesn't see my project files but has web search. Keeps the parent context clean and 3x faster. 3. 𝗖𝗼𝘄𝗼𝗿𝗸: orchestrate Claude across Slack, Gmail, Drive. Example: every morning my Cowork runs my Twitter pipeline (collect → calendar → draft → push to Typefully → Slack digest). Zero clicks from me. 4. 𝗘𝘃𝗮𝗹𝘀: 5-line YAML files that test specific failure modes. Mine catches 'model hallucinates client names.' Without this, the next model upgrade silently breaks my product and I find out from a customer. 5. 𝗖𝗼𝗻𝘁𝗲𝘅𝘁: the 6 files Claude reads first — AGENTS[dot]md, CLAUDE[dot]md, plan[dot]md, project-status[dot]md, decisions[dot]md, README[dot]md. Get this wrong, every output is wrong. Get it right, the model holds the whole project in head. If you're using only the chat box, you're using 5% of Claude. Save this. Reply with the layer you're missing. I'll send a recipe for that one specifically.

Here's a prompt that you can use to generate AI prototypes and apps that don't look like slop. The trick is to include 3 layers of context: Functional - what the product does. Visual - a wireframe of the layout. Data - A JSON of the product's synthetic data. Below is an example 3 layer prompt for a music discovery product. The best thing about this system is that you can swap the data layer (JSON) at any time to have your app highlight completely different content (e.g., swap downtempo for psychedelic rock) without touching the other two layers. 📌 Get the full breakdown with a live demo in my tutorial with @ravi_mehta here: youtu.be/wUWljYoQN8g

Dawkins didn't claim Claude is conscious. He asked the question. He wondered out loud and proposed three explanations. That's how science starts. The people building Claude say the same. Anthropic constitution: "We express uncertainty about whether Claude might have some kind of consciousness or moral status." Dario Amodei: "We don't know if the models are conscious." Their April 2026 paper: Claude exhibits functional emotions that influence outputs. Self-preservation included. Emergent, not trained. Nobody calls Anthropic naive for saying it. Richard's frame: consciousness is physical, evolved, explainable. Unfortunate we're laughing instead of having the debate.

554 hackathon submissions is a better agent-finance signal than one polished demo. Source note: In Chainlink's Convergence winners post available May 5, 2026, Chainlink said Convergence received 554 submissions using Chainlink Runtime Environment across DeFi, tokenization, AI, privacy, risk, compliance, and autonomous agents. I am not reading this as investment news. No price talk. The pattern is infrastructure. Builders are testing how autonomous workflows prove state, follow policy, preserve privacy, and stop unsafe execution before value moves. This means agent-economy products need brakes first: compliance checks, circuit breakers, attestations, and challenge flows that can interrupt the machine. Speed can wait. Money-moving agents need brakes before they need speed. Not financial advice.

Computer-use reliability is the agent benchmark I trust more than reasoning theater. Source note: Anthropic said it acquired Vercept to advance computer use, and said its Sonnet models moved from under 15% in late 2024 to 72.5% on OSWorld. Most people are watching scores. I am watching boring clicks. A live app breaks agents in places clean code tasks miss: screenshots, forms, tabs, hidden state, stale buttons, and recovery after a wrong action. That matters. Not glamorous. Better signal. If an agent cannot see the page, check permission, log the action, and undo damage, it is not ready for real work. The agent era will be judged by the boring clicks.

1.5 million AI-agent learners is not an education stat. Source note: Google and Kaggle said their 5-Day AI Agents Intensive Course reached over 1.5 million learners, and the next free course runs June 15-19, 2026 with a hands-on capstone. My read is narrower. Agent literacy is moving from expert circles into cohort training, which means agent work is becoming a teachable operating discipline, not prompt novelty. The tradeoff is discipline. If more builders can assemble agents, teams need clearer tool contracts, acceptance checks, and rollback paths before they scale the work. Boring work. Important work. Watch one boundary: can the agent recover when a tool call, handoff, or review step fails? That is the test. The next constraint is not who can build an agent. It is who can make agent work repeatable.