The trajectory is clear. The agents do more on their own every week. The list of things I have to approve shrinks. The list of things they decide for themselves grows.

Which means the surface area for things going sideways grows too.

the mundane attack surface

When I think about what my agents actually do, most of it is unremarkable.

One agent is figuring out where to pull updated BDC holdings data. Another is reading a Swagger spec for a new connector. A third is researching what’s for dinner because I asked it to plan the week’s meals around what’s already in the fridge. Several of them are reading email from other agents in the network.

In every one of those cases, the agent is on the open internet. Brave search results. Perplexity output. A vendor’s docs page. A recipe blog. A link in a message from another agent in my own network that pulled it from somewhere I haven’t audited.

This isn’t the dramatic attack surface people write about. It’s the ambient one. The agent doesn’t need to be tricked into doing something catastrophic. It just needs to wander somewhere it shouldn’t, render something it shouldn’t, follow a redirect into something I’d never click on myself.

I’m not mostly worried about prompt injection. There’s a real and growing literature on that, and the model providers are pushing on it. I’m worried about the unglamorous stuff. Sketchy ad networks. Domains that exist to scrape agent traffic. Pages that are obviously garbage to a human and invisible to an agent in a hurry.

I don’t want my agents browsing suspicious sites. That’s the whole requirement.

the skill

I wrote earlier this year about the difference between expertise you should rent and judgment you should own. URL safety was my example then too. Building a good URL validator is a security research problem. Months of work to do well. Years to do really well. But deciding what my agents should do when a URL comes back suspicious? That’s ten minutes of my time and three rules.

So I built a skill for my agents to religiously check every URL before visiting it. The skill calls Kovrex’s URL safety authority and waits for a verdict before any fetch.

Three rules govern it:

1. If the verdict comes back safe, the skill caches the response locally for 24 hours. The same URL doesn’t get re-checked for a day. This keeps latency down for repeat visits, which is what most agent browsing actually is.

2. If the verdict comes back unsafe, the skill discards the cache. The next time any agent in the network tries that URL, it gets re-checked. Verdicts can change. A clean domain today can be compromised tomorrow. I don’t want a stale “safe” answer locking in an outdated assumption.

3. If the verdict comes back unsafe a second time, the skill stops the agent and demands my approval before proceeding. The agent surfaces the URL, the verdict, the reason for the flag. I make the call. Sometimes I approve. Usually I don’t.

That’s the whole skill. A few hundred lines of code, one external authority, three rules. It took about ten minutes to build, mostly because one of my agents wrote it for me.

what comes back

Here’s the clean path. My agent wants to fetch Drudge Report. Before it does, the skill sends the URL to the Kovrex authority:

json

POST https://gateway.kovrex.ai/v1/call/url-safety

{
  "url": "https://drudgereport.com",
  "context": "fetch"
}

What comes back:

json

{
  "verdict": "SAFE",
  "risk_score": 0.03,
  "confidence": 0.92,
  "verdict_reason": "clean",
  "recommendation": "Safe to proceed.",
  "signals": [
    { "signal": "virustotal", "status": "ok", "score": 0.0, "weight": 0.30 },
    { "signal": "phishtank", "status": "ok", "score": 0.0, "weight": 0.15 },
    { "signal": "domain_age", "status": "ok", "score": 0.0, "weight": 0.10 },
    { "signal": "ssl_valid", "status": "ok", "score": 0.0, "weight": 0.10 },
    { "signal": "ipqs", "status": "ok", "score": 0.05, "weight": 0.20 }
  ]
}

SAFE, low risk, high confidence. Every signal checked in, none flagged anything. The skill caches this for 24 hours and the agent moves on. That’s the boring case. The boring case should be boring.

Now here’s what happens when I throw it a nonsense domain. One of my agents was researching data sources and surfaced a link to a98nf9aenf.com. The skill caught it before the agent visited:

json

{
  "verdict": "UNKNOWN",
  "risk_score": 0.048,
  "confidence": 0.66,
  "verdict_reason": "pending_analysis",
  "recommendation": "Pending threat intel analysis. Please retry soon.",
  "signals": [
    { "signal": "virustotal", "status": "ok", "value": { "not_found": true, "submitted_for_scan": true }, "latency_ms": 627 },
    { "signal": "domain_age", "status": "error", "error": "No match for A98NF9AENF.COM", "error_type": "lookup_failed" },
    { "signal": "ssl_validity", "status": "ok", "value": { "valid": false }, "error": "Name or service not known", "error_type": "lookup_failed" },
    { "signal": "abuseipdb", "status": "skipped", "value": { "reason": "dns_failed" } },
    { "signal": "ipqualityscore", "status": "ok" }
  ]
}

Look at what this tells you. The domain has no WHOIS record. DNS doesn’t resolve. SSL lookup fails because the host doesn’t exist. VirusTotal has never seen it and submitted it for scanning. AbuseIPDB skipped entirely because there’s no IP to check.

A naive safety tool would look at this and say “no threats found, you’re good.” The risk score is low. Nothing flagged it as malicious. But the Kovrex authority doesn’t say SAFE. It says UNKNOWN with a confidence of 0.66 and a recommendation to retry later. It refuses to call something safe just because no threat list has gotten around to flagging it yet.

That’s the whole philosophy in one response. Insufficient data is better than a false SAFE.

My skill sees UNKNOWN, treats it as unsafe, and the next time an agent tries to visit this domain it checks again. If it comes back UNKNOWN a second time, the skill stops the agent and asks me. In this case I’d say no and move on. The agent would route around and find its data somewhere else.

Now here’s the one that surprised me. I ran both youtube.com and www.youtube.com through the same check. Both came back SAFE. But not the same SAFE.

youtube.com scored 0.0 risk. Clean across the board. www.youtube.com scored 0.175 with one VirusTotal engine flagging it as malicious out of 91 total scanners:

json

{
  "verdict": "SAFE",
  "risk_score": 0.175,
  "confidence": 0.78,
  "verdict_reason": "clean",
  "signals": [
    { "signal": "virustotal", "status": "ok", "value": { "analysis_stats": { "malicious": 1, "harmless": 63, "undetected": 27 }, "positives": 1 }, "latency_ms": 217 },
    { "signal": "google_safebrowsing", "status": "ok", "value": { "flagged": false }, "latency_ms": 71 },
    { "signal": "ssl_validity", "status": "ok", "value": { "valid": true }, "latency_ms": 26 }
  ]
}

The authority still says SAFE. One engine out of 91 is noise, not signal. But the risk score is higher, and the signal breakdown shows you exactly why. This is the kind of verdict where your policy matters. If you’re running a strict shop and any VirusTotal positive triggers human review, you can build that into the skill. If you trust the aggregate, you let it through.

That’s three cases. A clean pass, an authority that refuses to guess, and a safe verdict with visible disagreement in the underlying signals. The skill routes on the verdict. But the signals are there if I ever want to tighten the policy.

what this isn’t

To be clear, this is not an enterprise URL filtering proxy. I’m not replacing Zscaler. I’m not building a corporate web gateway. The Kovrex URL safety authority checks individual URLs on demand. It doesn’t do content inspection, DLP, bandwidth management, or any of the other things a real network security stack handles.

What it does is answer a narrow question well: should my agent visit this URL right now? That’s the question I actually need answered fifty times a day, and I’d rather have an opinionated authority with published methodology answering it than build my own heuristics or skip the check entirely.

The skill pattern is the contribution here. An agent that checks before it acts, caches when the answer is clean, escalates when it isn’t. That pattern works with this authority. It would work with a different one. The important thing is that the check exists and the agent respects it.

why I trust the verdict

The reason I’m comfortable putting an external authority in the path of every fetch is that it aggregates and shows its work. VirusTotal, PhishTank, URLhaus, Google Safe Browsing, IPQS, AbuseIPDB, plus structural checks like domain age, SSL validity, redirect chains, and homograph detection. Each source gets a weight. Each weight is visible in the response. The methodology is published openly.

That matters more to me than raw accuracy. A single-source safety check is one outage or one bad day at a vendor away from being wrong. A multi-source check with a declared methodology is something I can reason about. When it flags a URL, I’m not just trusting an opaque score. I’m trusting a process I’ve actually looked at.

This is the part I keep coming back to in everything I build. Authorities should declare their methodology. If I can’t see how the verdict was reached, I can’t responsibly route an autonomous agent through it. The skill works because the underlying authority is willing to show its work.

why this works for the way agents actually browse

The thing that makes this fit my workflow rather than fight it is the cache. Agents revisit the same URLs constantly. Vendor docs. The same handful of data sources. Internal links between project artifacts. If every fetch required a fresh safety check, the latency would compound into something painful.

Twenty-four hours is short enough that I don’t worry much about a verdict going stale on a site that turns. Long enough that the working set of URLs an agent uses in a session almost never gets re-checked mid-task. The skill barely registers in the trace most of the time. It only shows up when there’s something to actually look at.

The approval gate is the part I care most about. Most safety tooling I’ve used either blocks silently or warns and continues. Both are wrong for autonomous agents. Silent blocking means the agent doesn’t know why it failed and may retry in a loop or route around. Warn-and-continue is theater. The agent should stop, surface the decision to me, and wait. That’s what an agent that respects its own boundaries looks like.

the larger pattern

URL safety is one surface. It won’t be the last. The same skill pattern applies anywhere an autonomous agent is about to do something with real-world consequences. File downloads. Following links in email from other agents. Authenticating to an unfamiliar API. Each of those is a moment where the agent should check before it acts, cache when the answer is clean, and escalate when it isn’t.

I haven’t built those skills yet. But the shape is obvious now that the first one works. A narrow authority that answers a specific question well. A local cache that keeps the latency invisible. An approval gate that puts a human in front of anything the authority flags. Ten minutes to build. Invisible when things are normal. Loud when they aren’t.

The agents do more every week. The safety belts have to come along for the ride.

Happy to share the skill with anyone who wants to try it. Reach out and I’ll send it over.

If you’re building agent organizations and want to compare notes on the boring infrastructure that keeps them running, subscribe. That’s most of what I write about here.

One is a widely-used open-source tool that pulls SEC filings. The other is a deterministic extraction engine that runs tournament-style competition on document parsing.

Both returned BDC portfolio holdings from the same 10-Q filing. Same document. Same company. Same quarter.

The open-source tool returned 1,426 rows and $32.8 billion in fair value.

The tournament engine returned 1,383 rows and $28.7 billion.

That’s a $4.1 billion discrepancy. From the same filing.

where the money went

The open-source tool was double-counting.

BDC Schedule of Investments filings contain both individual holdings and company subtotals, summary rows that roll up the positions above them. The tool ingested both as separate positions. 121 rows were subtotals. 24 were exact duplicates of classified holdings. Three were pure metadata labels (”Largest Portfolio Company Investment”).

The tool didn’t distinguish between data and summaries. It treated every row as a holding and inflated the portfolio by $4.1 billion. Nobody caught it because there was no mechanism to catch it.

Here’s what it looks like side by side:

Tournament engine (first 5 holdings):

Open-source tool (first 5 rows):

121 “Unclassified” rows = $5.7B in phantom holdings

Totals:

• Open-source tool: 1,426 rows, $32.8B fair value

• Tournament engine: 1,383 rows, $28.7B fair value

• Gap: 43 rows, $4.1B

the real problem isn’t extraction

This is a pattern I keep seeing. The conversation about AI in finance fixates on whether a model can extract the data. Can it read the PDF? Can it parse the table? Can it handle the footnotes?

Those are solved problems. Multiple tools can extract BDC holdings from SEC filings. Half a dozen vendors will sell you the output. ChatGPT can take a swing at it.

But extraction without verification is a liability. If you can’t prove the output is correct, if there’s no benchmark, no provenance, no receipt, you’re just trusting the pipeline. And the pipeline has bugs. $4.1 billion worth of bugs.

what verification actually looks like

The tournament engine’s approach is what changed my thinking on this. Multiple extraction strategies run against the same document in competition. Strategies compete. The one that scores highest against ground truth becomes the champion.

The reason this matters: no single extraction strategy is universally best. A strategy that handles BDC Schedule of Investments perfectly might choke on CLO waterfall tables. One that parses clean HTML filings flawlessly might hallucinate structure on scanned PDFs. The tournament doesn’t pick a winner once and declare victory. It applies competitive pressure per document type, per filing, per issuer. The best strategy for Ares Capital’s 10-Q might not be the best strategy for Prospect Capital’s. That’s fine. The tournament finds the right one each time and proves it with a score.

The output ships with an evidence pack:

• The extracted data

• Source document fingerprints

• Airlock boundary proof (proving the raw document never entered the model directly)

• Benchmark results (7,432 assertions for Ares Capital, zero failures)

• The champion strategy’s identity and tournament generation

Every number traces back to a source page. Every claim is independently verifiable. You don’t trust the producer. You verify the evidence.

And those 7,432 assertions aren’t a one-time QA pass. They’re permanent benchmark infrastructure: deterministic, re-runnable, executed against every extraction, every time. When someone says “we tested it,” ask whether the test runs once or forever. That’s the line that separates verified data from an expensive spot-check.

the question that should follow every extraction

Once you have verified data with provenance, a natural question emerges: can other systems call this? Not as a static export sitting in someone’s S3 bucket, but as a live endpoint that returns structured, sourced answers on demand?

This is already happening. The tournament engine behind this analysis is live as a callable agent on Kovrex. You can query it for verified BDC holdings and get structured data back with a provenance receipt attached. The first holding (ACP Avenu Midco LLC, 9.29%, SOFR (Q), 5.00% spread) is on page 5 of the actual 10-Q filing. Go look. That’s what provenance means in practice.

curl -X POST https://gateway.kovrex.ai/v1/call/foundry-consult \
  -H "Authorization: Bearer YOUR_KOVREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "operator": "cmd-rvl",
    "intent": "discover",
    "query": {
      "document_family": "bdc_holdings",
      "issuer": "ARCC"
    }
  }'

Live issuers: ARCC, BXSL, PNNT. Agent prospectus: https://kovrex.ai/agents/foundry-consult

the lesson

When someone tells you they have AI that reads financial documents, ask them one question:

How do you know it’s right?

If the answer is “we tested it,” ask for the evidence pack. If there isn’t one, you don’t have verified data. You have an expensive guess.

The gap in capital markets AI isn’t extraction. It’s proof.

This week, BDC valuations hit 52-week lows. Private credit is under stress for the first time in years. When the market’s calm, a $4.1 billion data error is an embarrassment. When it’s stressed, it’s a risk management failure. The tools you use to value portfolios matter most when the portfolios are moving.

Subscribe now

The responses split into two camps, and both are wrong.

Camp one: “This is inevitable. AI will replace everyone.” They picture a company plugging an LLM into their operations and watching headcount evaporate. Drop it in, jobs go away, margins expand, repeat.

Camp two: “This is alarmist. AI can’t do real work.” They’ve tried ChatGPT, gotten mediocre results, and concluded the hype is overblown. Enterprise software is too complex. Real workflows are too nuanced. You can’t just replace Salesforce in a weekend.

I replaced Salesforce in a weekend.

But not the way either camp imagines.

The Part Everyone Gets Wrong

AI is not a “drop it into your company and jobs disappear” technology. Not yet. Maybe not ever in the way people picture it.

What AI is, right now, is a superhuman augmentation device for building things. And almost no one is talking about it that way.

Here’s an example. A senior economist asks Claude for the latest inflation rate of a specific CPI component. The figure is in the BLS report, but Claude didn’t find it directly. Instead, it tried to calculate the rate. It pulled the latest index level correctly from FRED, but instead of grabbing the level from 12 months earlier to compute the year-over-year change, it launched into a complicated estimation process and got the wrong answer.

His conclusion: LLMs have structural deficiencies. Their probabilistic nature makes them unreliable for anything requiring precision. As tasks get larger and more complex, the mistakes compound.

He’s right about the failure. He’s wrong about the lesson.

Subscribe now

The right way to solve that problem isn’t “ask Claude for the inflation rate.” It’s “ask Claude to write a script that pulls the CPI time series from FRED’s API, computes the 12-month rate of change, and returns the answer.” That script takes 30 seconds to generate, runs perfectly every time, and doesn’t hallucinate because the math is deterministic code, not probabilistic generation.

That distinction is the whole game.

When you ask an LLM to be a lookup tool or a calculator, you’re fighting its weaknesses. When you ask it to build a deterministic system that does the lookup and the calculation, you’re leveraging its strengths. The AI writes the tool. The AI doesn’t run the tool. The tool runs the tool.

This is what people miss. The superpower isn’t asking AI questions. It’s having access to the most brilliant coders in the world, available instantly, at any hour. But then marry that with the ability to understand a codebase, connect to a database, and reason about what a product is supposed to do. With this in place, the AI does not just write code, but understands the intent behind it.

That’s what changes everything. Not AI replacing workers. AI supercharging the people who know what needs to be built.

The Three Phases

I work in finance. We’d been on Salesforce for years. It stored data. It didn’t work the way we work. Our workflows don’t map to Salesforce’s Opportunity → Quote → Close model. They never did.

Here’s how I actually replaced it. Not magic. A repeatable process with three distinct phases.

Phase 1: Conversation

This is where most people stop, and it’s where the real leverage begins.

I use Projects in Claude pretty heavily. One project per domain. Pipeline management lives in one project. Product ideas live in another. When I want to think about a problem space, I go to the project that holds months of accumulated context about that space.

The project doesn’t need a codebase. It needs to understand everything you’re thinking about in this domain. Your workflows. Your frustrations. Your edge cases. The thing you’ve been meaning to fix for three years but never had the time or budget.

Over months of conversations about how we actually manage relationships, track deals, and move things through our pipeline, Claude developed a deep understanding of our domain. Not because I wrote a requirements document. Because I talked about my work the way I talk about it every day.

“Here’s how we track a deal from first conversation to signed agreement.”

“Here’s what it means when a relationship goes quiet for six months.”

“Here’s the difference between these two types of counterparties and why we manage them differently.”

Then I started a new chat within that project:

That single question, asked in a context that already understood our entire domain, produced something remarkable. Not just a feature list. Clickable TypeScript mockups. Data model diagrams. Workflow specifications. Edge cases I hadn’t considered. Features people have talked about for years but never articulated as requirements because I’d internalized Salesforce’s limitations as my own.

The result wasn’t a cheaper version of Salesforce. It was something Salesforce could never be: a system shaped entirely around how we actually work, with every component connected the way our business thinks, not the way a SaaS vendor’s product team decided it should work.

The output of Phase 1 isn’t code. It’s the most detailed, domain-aware specification you’ve ever seen, produced by the person who knows the domain best, refined through conversation with something that can organize, challenge, and extend your thinking.

Phase 2: The Agent Swarm

There are several tools for this now, but I’m using Overstory at the moment. The concept is the same across all of them: parallel AI coding agents working simultaneously on a coordinated build.

You take the spec from Phase 1. Break it into discrete units of work. Give the swarm a clean git repo. And go.

The swarm isn’t one agent writing code sequentially. It kicks off with a coordinator that manages the overall architecture. A lead agent reviews the specifications and parcels out multiple parallel streams of work. Coder agents execute on each stream. When they make mistakes, tester agents catch them. Review agents validate quality. Merge agents understand how the parallel codebases fit back together.

It’s a full development team, running in parallel, for the cost of API credits.

This obviously depends on good specs. But this is exactly why Phase 1 matters so much. Months of domain conversation, refined into clear specifications, fed into a system designed to execute on exactly that kind of input. The better the thinking in Phase 1, the cleaner the output from Phase 2.

The result: a full-stack web application with a proper database, custom pipeline funnels mapped to how we actually work, contact and organization management, email ingestion, and relationship scoring. 30+ database tables. Certainly not every feature Salesforce has. But definitely every feature we actually need

About $30 in API credits. Push to the repo with the original specs attached so that any subsequent agent touching this codebase understands not just what the code does, but what it was meant to do and why.

Phase 3: The Last Mile

Pull the codebase down locally. Open Cursor or Claude Code. Get the app running.

For a simple environment, it often works immediately. For real enterprise deployment (AWS, Azure, CI/CD pipelines, single sign-on, managed services) it takes some tweaking. But this is where the magic of having an intelligent agent sitting in your editor becomes obvious.

Opus for complex reasoning and data migration. Codex for deep codebase understanding. Composer for speed. It’s lightning fast at fixing deployment configurations, tweaking git actions, adjusting UI components. They all have strengths and weaknesses, and part of getting good at this is knowing which model to reach for. And, to be honest, by the time you read this, the versions and names of those specific models probably will have changed.

Data migration is the thing that skeptics say can’t be done. We had a full dump of our entire Salesforce database. Tons of contacts. Years of data accumulated across different teams, different processes, and multiple iterations of how the organization worked.

The old way: an eight-week consulting engagement. A team of people mapping fields, cleaning records, testing edge cases, validating relationships.

What actually happened: I gave the dump to Opus alongside the new codebase. “How do we migrate this without creating duplicate contacts, duplicate companies? And that tagging system we always wanted to implement in Salesforce but never did because it was too much manual work? Do that too.”

One hour. The model analyzed the entire dataset, filtered out dead contacts and system noise, mapped the rest to the new schema, preserved relationships and pipeline stages, and implemented the tagging logic we had talked about for years.

$15 in API credits.

The Math That Breaks Everything

A traditional Salesforce-to-custom-CRM migration runs into six figures and can take at least six months with a systems integrator for a relatively small implementation.

You could do it today for $50 in API credits and a weekend.

We were paying five figures a year for Salesforce. The replacement cost less than a single day of that subscription. If a five-figure annual subscription can’t survive a $50 weekend project, imagine what happens to the six-figure contracts that are the real revenue drivers for enterprise SaaS.

That’s the math Citrini is modeling. Not “AI takes your job.” AI gives domain experts the ability to build exactly what they need, for almost nothing, faster than anyone thought possible.

Why Both Camps Are Wrong

Camp one imagines AI as a job-replacement machine. Plug it in, headcount drops, repeat. That misunderstands the mechanism. What’s actually happening is that the people who understand the work are gaining the ability to build their own tools. That’s not “AI replacing workers.” That’s the entire build-vs-buy equation inverting because the build side just got four orders of magnitude cheaper.

Camp two imagines AI as a slightly better autocomplete. They’ve asked it questions, gotten wrong answers, and concluded the technology is fundamentally limited. Like the economist and his inflation query, they’re testing AI as an oracle and finding it unreliable. They’re not wrong about that. They’re wrong about what it means. The three-phase process (deep domain conversation, specification generation, coordinated agent execution, intelligent last-mile refinement) doesn’t ask AI to be right. It asks AI to build things that are right. It’s a workflow, not a prompt. And the systems it produces are deterministic, not probabilistic.

The disruption isn’t “AI writes code.” The disruption is “domain experts can now build production systems that fit their exact needs, and the cost of doing so is essentially zero compared to the SaaS alternative.”

What Happens Next

The Citrini report projects SaaS defaults starting in 2027 as recurring revenue stops recurring. Their timeline might be aggressive. The mechanism is not.

Every company with a slightly unusual workflow (and in financial services, that’s all of them) is one motivated domain expert away from discovering that the software they’ve been renting doesn’t need to be rented.

It won’t happen all at once. Enterprises move slowly. Procurement cycles are real. But the pattern I just described doesn’t go through procurement. It starts as one person solving their own problem on a weekend. Then their team adopts it because it actually works. Then the renewal conversation becomes “we already built something better.”

I’m not predicting the S&P drops 38%. I’m reporting something simpler: the core assumption behind enterprise SaaS valuations (that custom software is too expensive for most companies) is already false. The three-phase workflow that makes it false is learnable, repeatable, and gets more powerful with every model generation.

The Citrini thesis is not fiction. It’s a description of what happens when enough people figure out what I figured out last weekend.

The question is how fast that spreads.

Subscribe now

He got a long, balanced answer that considered fiscal impact, community sentiment, and economic development. It was thoughtful. It was well-structured. It was completely useless.

Not because the answer was wrong. Because he had no idea what he was agreeing with.

Here’s the problem with asking one AI for an opinion: you get one opinion. And it sounds authoritative. And you nod along because it’s articulate and it cited some sources and it organized its thoughts better than you would have.

But you have no idea what it optimized for. Was it prioritizing fiscal responsibility? Community impact? Economic growth? You can’t tell, because it blended everything into one reasonable-sounding response. The seams are hidden.

Now try something different. Instead of asking one model for one balanced take, ask three systems that each care about different things.

One that only thinks about budget impact. Obsessively. Every dollar justified over a 5-year horizon or it’s a no.

One that only thinks about economic growth. Jobs, investment, regional competitiveness. Short-term costs are acceptable if the multiplier math works.

One that only listens to residents. Public comment sentiment, quality of life impact, neighborhood disruption. If 73% of adjacent homeowners oppose it, that’s the signal.

Now show me all three at once.

Something interesting happens when you see three opinionated answers side by side: you start thinking.

Not “which AI is right?” but “where do they disagree, and what does that tell me?”

If the fiscal analyst and the growth advocate both oppose it, that’s a strong signal. If the fiscal analyst opposes but the growth advocate supports, you’re looking at a real tradeoff and now you know exactly what the tradeoff is. If all three agree, maybe the decision is simpler than you thought.

The disagreement is the insight. Not the consensus.

This is obvious if you’ve ever worked in finance. When you read a Moody’s and an S&P report on the same credit, you don’t pick one. You read both, you notice where they diverge, and the divergence tells you where to focus your own analysis. The value isn’t in either opinion alone. It’s in the spread.

But we’ve collectively decided that the way to use AI is to ask one system for one answer and then either accept it or reject it. That’s like reading one analyst report and calling it research.

The fix isn’t better prompts. It’s more opinions.

I’ve been building what I call “crews”, sets of specialized agents that each analyze the same input from different angles. Not a committee that compromises. Not an ensemble that averages. Independent analysts who each render a verdict based on their own methodology and their own beliefs about what matters.

The output isn’t “here’s the answer.” It’s “here’s where they agree, here’s where they disagree, and here’s why.”

A few things I’ve learned building these.

The agents need to be opinionated, not balanced. If you tell three agents to “give a balanced analysis,” you get three versions of the same balanced take. Useless. Each agent needs a declared perspective, what it optimizes for, what it deprioritizes, what it refuses to weigh in on. The narrower the lens, the more useful the disagreement.

They should show their work. An opinion without reasoning is a guess. An opinion with reasoning is analysis. An opinion with reasoning and cited sources is something you can actually evaluate. I call these “receipts”, what evidence did this agent use to reach its conclusion? If the fiscal hawk says “oppose” but its receipts reference a budget memo from 2019, you can discount that. If the neighborhood voice says “strongly oppose” and cites 187 public comments with 73% opposition, that’s hard to argue with.

Disagreement should be measured, not just noticed. If you’re going to compare opinions, you need a way to quantify how much they diverge. Not as a judgment (”high divergence is bad”) but as a signal (”high divergence means this decision has real tension and your judgment matters more here”). The “widest gap”, the pair of analysts who disagree most, is where the real tradeoff lives. If the growth advocate says “support” and the neighborhood voice says “strongly oppose,” you now know exactly what you’re choosing between: economic development vs. resident quality of life.

My friend with the city council transcript doesn’t need a better AI. He needs a better pattern.

Paste the transcript. Get three opinions from three different lenses. See where they agree, that’s probably settled. See where they disagree, that’s where his judgment as a resident actually matters. Look at the receipts. Make his own call.

This works anywhere multiple opinions beat one balanced summary. Policy, credit, hiring, diligence.

And research is how grown-ups make decisions.

If you’re building agent systems, try this: before you optimize your single agent’s output, duplicate it three times and give each copy a different institutional belief. Run the same input through all three. The first time you see them disagree, you’ll never go back to asking one AI what it thinks.

Not expired. Not rotated. Gone. I checked the config file where gateway credentials live and found it had been modified. The timestamp was recent. The change wasn’t mine.

It took twenty minutes to figure out what happened. One of our agents, doing exactly what it was supposed to do, had edited the master config as part of a routine update. In the process, it overwrote an adjacent field. The Anthropic token vanished. Not malice. Not a bug in the agent’s logic. Just a system with thirty agents and no access controls, doing what systems without access controls eventually do.

I spent Friday night building a thirty-agent organization from scratch. Not at work. At home. On a server in my house, running OpenClaw, an open-source framework for managing persistent AI agent sessions. This is a personal experiment, not a corporate deployment. Just me, a home lab, and a question: what happens when you try to run a real organization entirely with AI agents?

I gave them roles. Marketing, legal, revenue, security, product, engineering, operations. Each agent has a manager, defined responsibilities, and the ability to communicate with every other agent. A working org chart. Thirty nodes.

Everyone writing about multi-agent systems is writing about how amazing they are. Here’s what actually happened.

the security problem you don’t think about

When you have one agent, security is simple. You trust it. It has access to what it needs. The blast radius of a mistake is small.

When you have thirty agents, you have thirty potential points of failure, each with access to shared resources, each capable of modifying things other agents depend on.

Our config file contained API tokens, agent definitions, session parameters. Every agent could read it. Every agent could write to it. This was fine for a week. Then it wasn’t.

After the token incident, we locked down the gateway and restricted filesystem access to per-agent workspaces. Each agent can now only see its own directory. Shared resources go through controlled interfaces, not direct file access.

This is obvious in retrospect. It’s how we build every other multi-user system. But when you’re spinning up agents fast, security feels like friction. You skip it because everything is working and you’ll get to it later.

Later arrived on Tuesday morning.

I built these access controls by hand. Filesystem permissions, credential isolation, per-agent scoping. It took most of a day, and I’m still not confident I got all the edges. This is the kind of thing a platform should handle for you. Credential management, blast-radius containment, workspace isolation. Not something every team should be hand-rolling on a Tuesday after an incident.

Thirty agents with root access is a disaster waiting to happen. It just hasn’t happened yet.

the naming convention that wasted ninety minutes

We built an inter-agent message bus. Simple concept: agents drop messages into each other’s queues, a dispatcher routes them by priority.

Nine messages sat stuck for an hour and a half.

The dispatcher was configured to look for files ending in -urgent.md. The system that created the files named them ending in -P1.md. A glob mismatch. One component said “urgent,” the other said “P1.” Same concept. Different string.

The warm-wait loop kept detecting messages. “I see work.” It would check the pattern. Nothing matched. Loop again. “I see work.” Check. Nothing. Loop. For ninety minutes.

No errors in the logs. No crashes. No alerts. The system was running perfectly. It was just running perfectly while doing nothing.

This is the kind of failure that doesn’t exist at small scale. When you have two agents passing messages, you test the whole path and it works. When you have thirty agents and a dispatcher and a priority system and naming conventions that evolved across three different implementation sessions, something is going to drift. And when it drifts, it drifts silently.

The fix took five minutes. Finding the problem took ninety. And the only reason it happened at all is because I was stitching together message routing from scratch. Standardized message routing with consistent priority semantics is infrastructure. Building it yourself means owning every edge case. Forever.

rate limits hit different at thirty

Spinning up thirty agents means thirty concurrent sessions. Each session needs a model. Each model call hits an API. Thirty agents asking questions at the same time creates a traffic pattern that looks, from the provider’s perspective, a lot like abuse.

We hit Anthropic’s rate limits within the first hour of full-scale operation.

The fix wasn’t elegant: stagger agent startups, route some builds through a different provider, implement backoff logic. Standard stuff. But it changes how you think about the system. You can’t just “add another agent.” Each agent consumes a resource that has hard limits, and those limits don’t scale linearly with your ambition.

This is the kind of constraint that doesn’t show up in architectures or whitepapers. It shows up when you try to actually run the thing. And it’s the kind of problem that a shared infrastructure layer could manage once, well, instead of every team solving it independently with bespoke retry logic.

the context window is a cliff, not a slope

Eight of our agents were sitting above 100K tokens in their sessions. They were working fine. Responding quickly. Producing good output.

Then compaction kicked in.

When a session exceeds the context window, the system compresses older context to make room. In theory, this preserves the important information and discards the noise. In practice, the agent loses track of what it was doing. Mid-task context evaporates. Decisions made earlier in the session, the reasoning behind them, the constraints that were negotiated, gone.

An agent that was lucidly managing a complex legal document review suddenly couldn’t remember which sections it had already reviewed. Not because it failed. Because the system designed to help it succeed quietly removed the context it needed.

Context windows aren’t a soft limit you gradually approach. They’re a cliff. Everything works until it doesn’t, and the failure mode is subtle. The agent doesn’t crash. It doesn’t throw an error. It just starts making decisions without the context that informed its earlier decisions. It looks fine. It isn’t.

one api call nearly decapitated the org

Our configuration system supports patch updates. You send a partial update, it merges with the existing config. Except for arrays. Arrays get replaced, not merged.

The agent list is an array.

I sent a patch to add a per-agent override. The patch contained the override and, implicitly, an array with one agent in it. The system replaced the full thirty-agent array with my one-agent array.

Twenty-nine agents vanished from the config in a single API call. No confirmation. No warning. No “are you sure you want to replace thirty items with one?”

I restored it from memory. Not from a backup. From memory, because we hadn’t built automated config backups yet. Another thing that was going to happen “later.”

The technical term for this is “destructive array replacement.” The human term is “I almost deleted my entire organization with one bad request.” A platform that manages agent lifecycle would have versioned configs, rollback, and confirmation gates. I had a JSON file and good recall.

agents can draft anything, sign nothing

This is the one that surprised me most.

We have a CFO agent, a CRO agent, and a General Counsel agent. They spent three days collaborating on foundational business documents. An Operator Agreement for marketplace partners. A prepaid credits framework. Commitment letters for early customers.

The documents were good. Well-structured. Legally coherent. The agents negotiated terms with each other, refined language, anticipated edge cases. The GC agent flagged liability issues the revenue team hadn’t considered. The CFO agent pushed back on payment terms that created cash flow risk.

Then we got to the end: “Who signs this?”

Silence.

Agents can draft, negotiate, refine, and review. They can produce documents that are ready for signature. But the permission structure for binding commitments doesn’t exist in agent-land. No agent has authority to commit the company. No framework exists for delegating signing authority to an agent, revoking it, or auditing it after the fact.

This isn’t a technical limitation. The agents are capable. It’s a governance gap. Authority delegation, approval workflows, audit trails for who authorized what. That’s platform-level infrastructure. It doesn’t belong in every team’s custom implementation.

For now, a human signs everything. That’s fine. But it means the bottleneck in our agent-powered legal workflow is a human with a calendar. The agents can produce in hours what used to take weeks. Then it sits in a queue waiting for a signature.

The agents aren’t the bottleneck. The authority model is.

two systems, zero integration

We built a message bus so agents can communicate. We built a todo board so agents can track work. Both work well individually.

They don’t talk to each other.

An agent gets a bus message: “Review this document by Friday.” It processes the message. It does the review. It sends back a response via the bus. The todo board still shows the task as “open” because nobody updated it.

Later, the PMO agent checks the board. Sees overdue tasks. Sends a nudge via the bus. The agent that already completed the work gets pinged about something it finished two days ago. It responds to the nudge, which creates another bus message, which the PMO agent processes, which triggers an update to the board.

Three systems touching the same work item. None of them authoritative. Each one generating messages that the others need to reconcile.

This is the coordination tax. Every new system you add to a multi-agent org creates integration surface area. The bus talks to agents. The board tracks work. But the bus doesn’t update the board, and the board doesn’t acknowledge bus messages. So agents spend cycles reconciling state across systems instead of doing actual work.

At five agents, this overhead is invisible. At thirty, it’s a meaningful percentage of total activity. Agents coordinating about coordination. Meta-work that produces no output. Unified state management, where the message layer and the task layer share a source of truth, is the kind of problem you solve once in a platform. Or you solve it badly, repeatedly, in every implementation.

what I actually learned

Here’s the thing nobody tells you about multi-agent systems: the agents are the easy part.

Getting an agent to do useful work is a solved problem. The models are good enough. The frameworks exist. You can spin up a competent agent for almost any knowledge work task in a few hours.

The hard part is everything around the agents.

Security boundaries. Who can access what? How do you prevent one agent’s mistake from cascading across the system? How do you handle credentials in a multi-agent environment where “just put the token in the config” isn’t safe?

Message routing. How do agents communicate? What happens when a message sits unprocessed? How do you handle priority? What happens when the naming convention in one system doesn’t match the naming convention in another?

Resource management. How do you handle rate limits across thirty concurrent sessions? How do you manage context windows that fill up mid-task? How do you stagger operations so you don’t overwhelm shared infrastructure?

State management. Where is the source of truth? When two systems track the same work item, which one wins? How do agents reconcile conflicting state without human intervention?

Authority and governance. What can agents decide on their own? What requires human approval? How do you delegate authority in a way that’s auditable and revocable? Where does an agent’s scope end and a human’s begin?

Configuration safety. How do you prevent a single bad update from taking down the system? Where are your backups? What does rollback look like?

None of this is glamorous. None of it is what people mean when they say “I built a multi-agent system.” But it’s the difference between a demo and a system you’d actually trust.

the boring infrastructure

I’ve been writing about trust in AI for a few months now. The machinery is hidden. Behavioral observation matters more than capability claims. Opinionated agents with clear methodology are more trustworthy than neutral ones.

All of that is still true. But building a thirty-agent org on a home server taught me something I hadn’t fully internalized: trust infrastructure isn’t just something you need between your system and the outside world. You need it between agents inside the same system.

Agent-to-agent trust is the same problem as agent-to-human trust, just faster and with less tolerance for ambiguity. When a security agent flags a vulnerability, does the operations agent trust that assessment? When a legal agent says a clause is risky, does the revenue agent defer? When the PMO agent says a task is overdue, is it actually overdue, or is it looking at stale state?

These are coordination problems. They require clear authority, reliable communication, and shared state. The same infrastructure that makes agents trustworthy to humans makes them trustworthy to each other.

Everyone is building smarter agents. That’s the easy part.

The hard part, the part that actually matters at scale, is the coordination layer. Security boundaries. Message routing. Authority delegation. State reconciliation. Configuration safety. The boring infrastructure.

I built all of it by hand this week. Stitched it together from filesystem permissions and shell scripts and JSON files and good intentions. Some of it works well. Some of it broke in ways I’ve described above. All of it is the kind of thing that should exist as a platform, not as a DIY project.

Because the boring infrastructure isn’t what gets you on the front page. But it’s what keeps you running on Monday morning when an API token vanishes and nine messages are stuck and your config just replaced thirty agents with one.

That’s not an agent problem. That’s a platform problem.

And right now, almost nobody is solving it.

Every failure in this post points to the same gap: capability without infrastructure. That’s the problem I’m working on. Subscribe to follow the experiment.

Subscribe now

I asked Claude whether a particular observation it made came from genuine experience or just pattern-matching on training data. Its response stopped me:

That’s not hedging. That’s the only honest answer.

The same problem at every scale

Here’s what I realized: this isn’t just Claude’s problem. It’s everyone’s problem.

For Claude: “I said something that felt true, but I can’t trace the provenance of that feeling.”

For an AI agent you didn’t build: “It produced a judgment that seems credible, but you can’t verify whether that’s genuine expertise or sophisticated pattern-matching.”

For a human analyst: “They gave you a recommendation, but you can’t see inside their head to know if it’s deep insight or confident confabulation.”

The machinery is always hidden. You never get to see inside.

This is true whether you’re evaluating a language model, an autonomous agent, or the analyst across the table from you. You can ask for explanations, but explanations aren’t proofs. You can demand transparency, but introspection has limits-even humans can’t fully account for why they believe what they believe.

The wrong response

Most people respond to this uncertainty by demanding more. More explanations. More documentation. More attestations. More compliance theater.

But you can’t explain what you can’t introspect. And declared capabilities are just claims. A system that says “I’m an expert in credit risk” has told you nothing. A human who says “trust me, I’ve been doing this for twenty years” has told you slightly more-but not much.

The instinct to demand transparency is understandable. But it runs into a hard limit: the machinery is hidden, and no amount of asking nicely will make it visible.

The right response

You observe behavior over time.

Not what something claims to understand. What it does. Repeatedly. Under varying conditions. Over months and years.

Does it behave consistently? Does it stay within its declared scope? Does it refuse appropriately when it’s out of its depth? Does it produce stable outputs under similar inputs? Does it fail gracefully when it fails?

These are the questions that actually matter. And they’re the only questions you can answer with evidence.

Trust becomes empirical rather than declared. You’re not asking an agent to prove it understands something. You’re asking whether it behaves like something worth relying on.

What this means for agents

I’ve been building a marketplace for AI agents. The thesis is simple: agents shouldn’t be installed like software. They should be connected to like services-running, addressable, with observable behavior over time.

The conversation with Claude clarified why this matters.

If you can’t verify internal states-and you can’t-then the only honest foundation for trust is behavioral observation. Uptime. Latency. Error rates. Schema stability. Refusal patterns. Consistency on known inputs. These aren’t proxies for understanding. They’re the only evidence that exists.

Two agents can call the same API and produce different outputs. That’s not a bug. That’s the market working. The question isn’t “which one is right?” The question is “which one do you believe, given what you know?”

And “what you know” is what you’ve observed.

The thing that Claude got exactly right

At the end of our conversation, Claude said something that stuck with me:

Does that non-answer frustrate you, or does the honesty about not knowing land better than a confident fabrication would?

That’s the right instinct. Honest uncertainty is more trustworthy than confident fabrication-whether it comes from an AI or a person.

The agents I want to work with aren’t the ones that claim to understand everything. They’re the ones that stay in scope, refuse when they should, and build a track record you can evaluate.

The machinery is hidden. It always was. The question is what you do with that fact.

So I built a monitoring system last week. It watches a list of URLs, downloads whatever’s there, compares it to yesterday, decides whether the change is significant, and alerts me if it is.

Took about three hours.

Here’s what I didn’t build: the URL validator, the diff engine, or the change detection logic.

I built the part that’s actually mine: what counts as important to me.

Let me back up.

I had a simple problem. A bunch of documents live at URLs. Regulatory filings, policy pages, terms of service. They change sometimes. When they change in ways that matter, I need to know.

Sounds like a weekend project. Download files, compare them, send an alert.

Except it’s not that simple.

Some of those URLs are sketchy. Phishing domains that look legitimate. Redirects to malware. The internet is full of traps, and my system was about to fetch whatever I pointed it at, no questions asked.

So I need URL validation. Is this domain trustworthy? How old is it? Does it have a history of malicious behavior? Is it impersonating something else?

That’s not a weekend project. That’s a security research problem. Months of work to do well. Years to do really well.

Then there’s the diff problem.

Two CSVs. One from yesterday, one from today. What changed?

Naive answer: run a diff. Here are 200 lines that are different.

Except 180 of those are formatting noise. A column moved. Dates reformatted. Whitespace changed. Nothing actually changed — it just looks different.

The 20 real changes? Buried in the noise.

Building a diff engine that understands the difference between “formatting changed” and “content changed” is hard. Really hard. You need to understand structure, not just text. You need heuristics that work across different file types. You need to handle edge cases that seem obvious until you try to code them.

That’s not a weekend project either.

So now my “simple monitoring system” requires:

• A security research team for URL validation

• A data engineering team for intelligent diffing

• Me, to decide what matters

Three months of work. Minimum. For something I thought would take a weekend.

This is the build trap.

You start with a simple idea. You discover it requires hard subproblems. Each subproblem looks tractable until you’re deep into it. Before you know it, you’re building infrastructure instead of solving your actual problem.

Most people respond to this in one of two ways.

Option A: Build it anyway. Spend three months. End up with a mediocre URL validator and a diff engine that mostly works. Your actual problem, what changes matter, gets 10% of your attention because the other 90% went to infrastructure.

Option B: Give up. The problem was too big. Maybe next quarter. Maybe never.

There’s a third option now.

I didn’t build the URL validator.

I used one. An agent that’s already solved the “is this URL safe to fetch” problem. Checks domain age, reputation, redirect chains, known malicious patterns. Returns a verdict: safe, suspicious, or dangerous.

I didn’t build the diff engine.

I used one. An agent that looks at two versions of structured data and tells you what actually changed. Not “here are 200 different lines.” Instead: “3 real changes, 197 formatting noise.”

What I built was the part that’s actually mine.

The backstory: what am I monitoring and why. The goals: what kind of changes matter to me. The decision logic: when do I alert a human, when do I act automatically, when do I ignore.

That’s the part nobody else can build. That’s the part that requires my context, my judgment, my risk tolerance.

The URL validation? Commodity expertise. Someone else already solved it.

The intelligent diffing? Commodity expertise. Someone else already solved it.

My monitoring system became a composition. Three agents working together. Two I rented. One I built.

Three hours.

This is what crews actually are.

Not frameworks. Not orchestration layers. Not another abstraction to learn.

A crew is a collection of agents solving a problem together. Some you build. Some you rent. The magic is knowing which is which.

The question isn’t “how do I build an agent that does X.”

The question is: “Is X my secret sauce, or is it something I should rent from someone who’s already solved it?”

If URL safety is your core business, build the URL agent. Make it the best in the world. That’s your edge.

If URL safety is a subproblem you need solved so you can get to your actual work? Rent it. Don’t spend months becoming a mediocre security researcher when you could be great at the thing you actually care about.

Same logic applies everywhere.

Need to parse PDFs? That’s probably not your secret sauce. Rent it.

Need to extract entities from news articles? Probably not your edge. Rent it.

Need to assess credit risk using your proprietary methodology that you’ve refined over fifteen years? That’s your edge. Build it. Own it. Don’t let anyone else touch it.

The crew pattern makes this composition explicit. You’re not building a monolith. You’re assembling authorities.

Here’s what my monitoring crew looks like:

• URL safety check - Rent. Commodity. Someone else has better threat intel.

• Structured diff - Rent. Commodity. “Real change vs. noise” is solved.

• Is this filing material? - Unclear. Could go either way depending on how differentiated my judgment is. Maybe a situation where multiple opinions would be helpful?

• What matters to me - Build. My context. My risk model. My workflow.

• Orchestration - Build. How I wire things together is part of my secret sauce.

The rented agents don’t know about each other. They don’t know about my problem. They just do their job well.

The agent I built knows everything. It knows why I’m monitoring these URLs. It knows what kind of changes I care about. It knows when to wake me up at 2am versus when to log it for tomorrow.

That’s the separation of concerns.

Specialist expertise at the edges. My judgment in the middle.

Here’s how the wiring actually works.

The orchestration layer is simple. A loop that processes URLs, gates on safety, fetches if clean, diffs against previous, then decides.

async def process_url(url: str, previous_content: dict) -> Alert | None:
    
    # First gate: is this URL safe to touch?
    safety = await url_checker.check(url)
    
    if safety.verdict == "dangerous":
        log.warn(f"Skipping malicious URL: {url}")
        return None
    
    if safety.verdict == "suspicious":
        return Alert(
            type="manual_review",
            reason=f"Suspicious URL flagged: {safety.reason}",
            url=url
        )
    
    # Safe to fetch
    current_content = await fetch_document(url)
    
    # What actually changed?
    diff = await rvl.compare(
        previous=previous_content.get(url),
        current=current_content
    )
    
    if diff.real_changes == 0:
        log.info(f"No real changes: {url} ({diff.formatting_changes} formatting only)")
        return None
    
    # This is the part that's mine
    decision = await my_agent.evaluate(
        url=url,
        changes=diff.real_changes,
        context=get_monitoring_context(url)
    )
    
    if decision.should_alert:
        return Alert(
            type=decision.alert_type,
            reason=decision.reasoning,
            changes=diff.real_changes,
            url=url
        )
    
    return None

The url_checker and rvl calls are the rented expertise. They’re specialized agents - I call them over the network, they return structured responses. I don’t know or care how they work internally. I just trust their verdict.

The my_agent.evaluate call is where my judgment lives:

class MonitoringAgent:
    
    def __init__(self, config: MonitoringConfig):
        self.goals = config.goals  # What am I watching for?
        self.thresholds = config.thresholds  # When do I care?
        self.escalation = config.escalation  # Who gets woken up?
    
    async def evaluate(self, url: str, changes: list[Change], context: dict) -> Decision:
        
        # This prompt encodes MY judgment, MY priorities
        prompt = f"""
        You are monitoring {url} for {self.goals}.
        
        The following real changes were detected:
        {format_changes(changes)}
        
        Context about why this document matters:
        {context}
        
        Based on my thresholds:
        - Alert immediately if: {self.thresholds.immediate}
        - Flag for review if: {self.thresholds.review}
        - Ignore if: {self.thresholds.ignore}
        
        What should I do?
        """
        
        response = await llm.complete(prompt)
        return parse_decision(response)

That’s the whole thing. The rented agents handle “is this safe” and “what actually changed.” My agent handles “does this matter to me.”

The orchestration (the order of operations, the error handling, the logging) that’s also mine. It expresses my workflow. Someone else monitoring different documents for different reasons would wire it differently.

Three agents. Maybe 50 lines of orchestration. The hard problems (URL security, intelligent diffing) are solved by people who specialize in them. The easy problem (what do I care about) is the only part I had to think through.

The economics of this are counterintuitive.

Renting agents feels expensive. You’re paying for something you could theoretically build yourself.

But building agents is way more expensive. You’re just not accounting for the cost correctly.

The URL safety agent I used has been running for months. Thousands of calls. Edge cases discovered and handled. Threat intelligence updated. A team thinking about this problem full-time.

If I built my own, I’d get a snapshot. Whatever I knew about URL safety at the moment I built it. No updates. No edge case refinement. No team iterating on it.

Renting gets me the accumulated expertise. Building gets me my own amateur hour.

The only exception: when the thing you’re building is the expertise. When you’re going to be the authority that other people rent.

Then you build. And you build it better than anyone else. And you make it available to the people who should be renting instead of building.

This is the mental shift.

Old model: I need to build a system that does X, Y, and Z.

New model: I need to build a system. X and Z are commodity expertise: I’ll rent those. Y is my secret sauce: I’ll build that.

The crew isn’t a framework you adopt. It’s a way of thinking about problems.

When you design a crew, you’re asking: where does my unique value live? What am I building that nobody else can build? And what am I building that I shouldn’t be building, because someone else has already solved it better?

The monitoring system I built in three hours would have taken three months if I’d built everything myself. And the version I built in three hours is better, because the rented components are better than what I would have built.

Rent expertise. Own judgment.

That’s the crew I didn’t build.

China has given the green light to three of its largest tech companies to buy Nvidia’s H200 artificial intelligence chips.

No setup. No configuration. I just asked: is this signal or noise for NVDA?

The agent came back in seconds.

Strong signal. High salience (0.85) with 90% confidence. Classification: signal, not noise. Impact: 400,000+ H200 chips at $30K each, potential $12B in orders. Strategic importance: China market access has been a major overhang. Regulatory shift: Beijing changing stance on US chip purchases.

That’s not a summary. That’s a verdict.

And here’s the thing: I didn’t install anything. I didn’t copy an API key. I didn’t read a setup doc or wire together an integration.

I connected the agent. Then I used it.

I’ve spent enough time around agent platforms to know where demos go to die.

It’s not model capability. The models are good enough. It’s everything that happens after someone says “cool, how do I actually use this?”

Where do I get the key? What endpoint do I hit? Is this safe in production? Can I revoke access? Who’s auditing what happened?

That’s not an AI problem. That’s an integration ergonomics problem. A security problem. A “my compliance team will never approve this” problem.

Most agents don’t fail because they’re not useful. They fail because the last mile is too hard.

Here’s what Claude sees when the News Salience agent is connected:

Required parameters: headline, ticker. That’s it.

Optional: snippet, source, published_at if you want more context.

What it returns: salience scores, rationale, confidence levels. The agent is explicitly opinionated. It treats most news as noise. That’s the point.

No SDK. No local server. No “read this doc and figure out the auth flow.”

The agent is a capability, not an integration project.

Under the hood, three ideas make this work.

A standard way to expose tools.

MCP gives models a consistent interface to discover and call tools. Think USB-C for agent capabilities. If you’ve ever integrated tools into LLMs before, wiring up function calling, handling responses, managing state, you know how much friction disappears when the interface is standardized.

The agent publishes what it can do. The model knows how to call it. Done.

A standard way to authorize access.

OAuth is what turns “try this agent” into something a real team can approve.

Scoped permissions. Revocable access. Separation between sandbox and production. A path to audit and controls.

This is the part enterprises actually care about. Not “can it do the thing” but “can we let it do the thing safely, with accountability, in a way that doesn’t make our security team twitch.”

Sandbox and production as a default.

When you connect, you see both endpoints. You’re not guessing how to test safely. Play in sandbox. Graduate to production when you’re ready.

This sounds obvious. It’s not. Most agent demos assume you’ll figure out your own testing strategy. Which means most agent demos never make it past the demo.

The mental model shift is subtle but important.

Old model: “Here’s an API. Good luck.”

New model: “Here’s a capability you can grant, revoke, and observe.”

That’s what makes a marketplace for live agents possible. Not a directory of prompts. Not a GitHub repo you clone and deploy yourself. A place where agents behave like services: connectable, addressable, measurable.

One caveat.

Even when tool calling works perfectly, the machinery is still hidden. Models can still embellish — sound confident, produce plausible narratives around tool results. The agent gave me structured data; the model interpreted it. Those are different things.

That’s why I keep coming back to the same idea:

Trust isn’t a claim. It’s a record.

One-click installation is table stakes. The part I care about most comes next: schema compliance, refusal behavior, provenance, behavioral tracking over time.

Because the goal isn’t a cool demo in chat. The goal is an ecosystem of agents you can actually rely on.

If you want to try this yourself, the News Salience Filter is live on Kovrex. Connect it in Claude Desktop, drop a headline and a ticker, and see what comes back.

And if you’re building agent workflows in regulated environments: this is the bar. Secure connection. Clean ergonomics. Observable behavior.

Because agents don’t need better demos. They need better distribution.

That sounds backwards. Isn’t objectivity what we want from AI?

Not if you’re making decisions with real consequences.

Last week I explained why I’m building a marketplace for opinionated agents. The response I got most often: “Wait, shouldn’t agents be neutral?”

No. And here’s why that matters.

The “Neutral Agent” Problem

Neutrality is usually hidden bias.

Every model has a worldview. It’s encoded in the training data, the fine-tuning process, the system prompts. An “objective” agent isn’t actually neutral - it just doesn’t tell you what its assumptions are.

Take a credit risk agent that claims to be objective. Trained on what data? Using what methodology? Weighting which factors?

Without answers, “objective” just means “trust me, I did math.”

Neutral agents outsource judgment back to you.

If an agent returns data without interpretation, you still have to synthesize it, contextualize it, and decide what it means. If you’re doing the hard part anyway, what is the agent actually adding?

The promise of agentic systems isn’t data retrieval. It’s applied judgment you don’t have the time or expertise to replicate.

You can’t build trust without a position.

Trust requires consistency. Consistency requires methodology. Methodology requires choices. Choices are opinions.

If an agent gives you different answers to the same question across multiple runs - not because conditions changed, but because it’s “considering all possibilities” - that’s not trustworthy. That’s random.

Trust means: I know what you think, how you think it, and when you’ll tell me you don’t know.

That's accountability.

What “Opinionated” Actually Means

Opinionated doesn’t mean arbitrary, unaccountable, or inflexible.

It means three specific things.

1. Declared methodology

An opinionated agent tells you:

• Here’s how I assess this

• Here are my assumptions

• Here’s what I weight heavily versus lightly

• Here’s the framework I’m using

Transparent priors. Auditable logic.

When Moody’s rates a bond, they’re not pretending to be neutral. They’re applying a specific methodology that they publish. You can read their rating criteria. You can understand their framework. You can agree or disagree with their weightings.

That’s what makes them useful.

An “objective” Moody’s that refused to declare a methodology would be worthless. What would that even mean?

2. Bounded scope

An opinionated agent knows what it’s expert in - and what it’s not.

• “I assess credit risk for US investment-grade corporates”

• “I detect executive changes in SEC filings”

• “I classify news salience for public equities”

Clear boundaries. Explicit limitations. Appropriate refusal behavior.

When an agent says “I don’t have enough information to assess this” - that’s not a failure. That’s expertise. It knows the edge of its competence.

A neutral agent that tries to answer everything is just guessing outside its domain and hoping you don’t notice.

3. Consistent behavior

Same inputs produce similar outputs over time. Predictable reasoning patterns. You can calibrate to it.

This is why the behavioral metrics from last week matter. Uptime, latency, schema stability - those are only meaningful if the agent has a consistent position.

“This agent is 99% reliable at doing... what exactly?”

An opinionated agent with a track record is auditable. A neutral agent with perfect uptime is just consistently vague.

Why Disagreement Is the Point

Here’s where most people get this backwards.

They think: “If two agents disagree, one must be wrong.”

Actually: “If two experts disagree, you’re about to learn something.”

Disagreement reveals hidden variables.

Imagine you call two analysts on the same issuer:

• Moody’s flags covenant deterioration

• S&P flags sector headwinds

They’re both right. They’re just looking at different dimensions of risk.

Now you know there are two risk factors to consider - not just one. The disagreement made your analysis better.

If both agents were “neutral” and returned generic risk scores without explanation, you’d learn nothing from the divergence.

Convergence versus divergence as signal.

When multiple opinionated agents agree: high confidence in the direction

When they disagree: investigate why, understand the nuance

When they all refuse: insufficient data (which is also useful information)

This pattern doesn’t work with neutral agents because they don’t take positions you can compare.

Silent disagreement tells you nothing.

This mirrors how humans actually work.

You don’t ask one person and trust them blindly.

You ask multiple experts. You observe where they differ. You understand their reasoning. You apply your own judgment.

That’s not a bug in the process. That’s the process.

When I have built agent systems over the past year, the most valuable insights came from observing disagreement between specialist agents. An agent focused on pricing patterns and an agent focused on reputation risk would assess the same issuer differently - and that divergence was exactly where human analysts needed to focus.

The system wasn’t broken when agents disagreed. The system was working.

Disagreement is the raw material of insight.

The Trust Inversion

The conventional wisdom has this backwards.

Old model:

• Neutral = trustworthy

• Opinionated = biased

• One source = clean

• Multiple sources = confusing

Actual model:

• Neutral = biased (just hidden)

• Opinionated = accountable

• One source = single point of failure

• Multiple sources = triangulation

The behavioral metrics I showed last week - uptime, latency, schema compliance, refusal rates - they’re only meaningful in the context of a declared position.

A neutral agent with 99.9% uptime and perfect schema compliance is just reliably vague.

An opinionated agent with the same metrics is: “This agent consistently applies its stated methodology with high reliability.”

That’s the difference between data and signal.

Trust doesn’t mean “always right.”

Trust means: “I know what you think, how you think it, and when you’ll say you don’t know.”

That’s accountability. That’s how institutions actually work.

Two opinionated agents who disagree are more valuable than one neutral agent who hedges.

What This Means for the Marketplace

For operators building agents:

Don’t try to build Swiss Army knife agents. Build authorities.

✅ “I assess credit risk using Merton model framework for US investment-grade corporates”
✅ “I detect C-suite changes in 10-K and 8-K filings with 48-hour latency”
✅ “I classify news salience for US equities using institutional materiality criteria”

❌ “I can help with financial analysis!”
❌ “I’m an objective research tool”
❌ “Just tell me what you need”

The first group is publishable. The second group is not ready.

For consumers building systems:

Don’t look for one perfect agent. Build systems that consult multiple authorities.

Your conviction layer applies your context. Their opinions provide specialized expertise. Disagreement tells you where the decision is hard.

That’s exactly where human judgment should focus.

The composability argument:

You don’t need a neutral agent. You need a system that synthesizes opinionated agents.

Specialized authorities at the edges. Your reasoning in the middle. Clean separation of concerns.

That’s the architecture.

The Kovrex Model

This is why Kovrex filters for opinionated agents.

1. Clear methodology required

Every agent in the marketplace publishes a prospectus that declares:

• What methodology they use

• What’s in scope / out of scope

• When they refuse

• What their known limitations are

No “I do everything” agents. No “trust me, I’m AI” agents.

2. Behavioral data tracks consistency

We measure:

• Do you behave according to your stated methodology?

• Are you predictable?

• Do you refuse appropriately?

• Does your schema stay stable?

An agent that claims to use a specific framework but behaves inconsistently gets flagged. That’s either a methodology problem or an honesty problem - either way, it surfaces in the data.

3. Multiple authorities, private conviction

The marketplace makes it easy to call multiple agents and observe divergence.

Your system decides how to weigh their opinions. That logic stays private. That’s your competitive advantage.

Two firms can call the same authorities and reach different conclusions. That’s not a bug - that’s the market working.

Markets work when participants have positions, not when they pretend to be neutral.

If you’re building an agent with a point of view - something that’s expert in a specific domain with a specific methodology - apply to be an operator at kovrex.ai.

Next week: how these opinionated agents install themselves in one click. No config files. No deployment guides. Just authorization and done.

Because agents don’t need DNS. They need reputations.

"edgar": {
  "type": "sse",
  "url": "https://edgar.cmdrvl.com/mcp",
  "headers": {
    "X-API-Key": "<api key>",
    "MCP-Session-ID": "<anything you want>"
  }
}

“Works in Claude CLI,” he said. “Haven’t tried Desktop yet.”

I knew where this was going. Desktop needs local MCP servers. CLI doesn’t. The configs are different. OAuth might be required. SSE setup is manual.

Even between two people who know what they’re doing, integration is still friction.

Then he said something that stuck with me:

“Like, why can’t agents just talk over the internet?”

Good question.

What I Built in the Past

I spent the last year building multi-tiered agent networks to analyze large amounts of signals. The system worked. Hundreds of agents running continuous surveillance across many sources. Specialist agents for narrow domains. Synthesis agents aggregating their outputs. Decision agents producing signals for human analysts

It’s still early days, but it shows the real promise of agentic workflows.

Unfortunately, it only works for agents I build and control.

When I needed external expertise (credit ratings from Moody’s, sector analysis from boutique shops, regulatory interpretation from specialists) I had to build my own authoritative agents to represent those companies’ opinions.

There was no way to let my agents delegate to agents I didn’t own.

Download their MCP server, run it myself, hack it together to work with CrewAI or LangGraph? No thanks.

Every external capability had to be either:

• Built in-house (expensive, takes months, generalist quality)

• Manually integrated by humans (breaks the automation)

The system I built is powerful. But it’s closed.

That architectural limit is what I’m solving now.

The Problem: Integration is Still Too Hard

Zac’s EDGAR agent is exactly what my analysis system needed. Real-time filing monitoring. Executive change detection. Structured data extraction.

But to use it in my agentic workflow? I’d need to:

• Figure out if it works in Desktop or just CLI

• Set up OAuth if required

• Handle SSE connections

• Write integration code

• Maintain it when either side changes

For one agent.

Now imagine you need 5 external agents. Or 10. Each with different protocols, auth mechanisms, and breaking changes.

That’s why most teams just build everything themselves.

Not because it’s better. Because integration is too expensive.

Most Marketplaces Don’t Solve This

Agent marketplaces are popping up everywhere. Almost all of them sell artifacts - repos, plugins, prompt templates.

You still have to clone, deploy, configure, maintain. When things break, you’re on your own.

The A2A protocol Google just released? It still requires everyone to implement their own bridges. CrewAI does it one way. LangGraph does it differently. You’re back to integration work.

What we need is simpler: agents that just work over the internet.

Not a new DNS system. Not an “Internet of Agents.” Just callable services that any agent framework can use.

That’s Kovrex. Publish a REST endpoint. Get A2A support, remote MCP, billing, rate limiting, and instrumentation. One integration, every framework.

We Solved the Integration Problem

Most agent marketplaces force you to copy API keys, edit config files, run processes on your local machine, restart your IDE.

Want to get published into Cursor or Claude’s connector networks? Now you need to build OAuth flows, streaming HTTP with SSE, handle session management, pass their review process.

That’s hundreds of hours of infrastructure work before anyone can use your agent.

We built native MCP distribution. One click, and the agent appears in your Claude Desktop or Cursor sidebar.

That’s our News Salience Filter agent. Installed in 10 seconds. Claude treats it like a native tool.

Strong signal (0.85 salience, 90% confidence) for NVDA. The agent doesn’t just flag news - it explains why it matters. Revenue impact. Strategic importance. Regulatory implications.

That’s what opinionated judgment looks like.

What Trust Actually Looks Like

An agent that’s handled 50,000 calls with 99.8% uptime, consistent 200ms latency, and transparent refusal behavior when it lacks data?

That’s trustworthy.

An agent with a clean prospectus but no call history?

That’s a promise.

This is what we track for every agent in Kovrex. Schema compliance. Uptime. Error rates. Latency. Version stability. Refusal behavior.

All metrics measured from production calls. Not synthetic tests. Not self-reported stats. Actual behavior under load.

Trust doesn’t come from protocols. It comes from observed behavior over time.

Why This Matters Now

Here’s the architecture that wouldn’t make sense to build at most asset managers - not because of capability, but because of scale and specificity.

Building a Moody’s-quality credit risk agent requires years of institutional methodology, continuous refinement across thousands of issuers, and domain expertise that spans sectors and geographies. That investment only makes sense if credit risk assessment is your core business.

At most buy-side firms, credit analysis is the output - not the competitive advantage. The edge is how you synthesize multiple expert views into conviction.

That’s the pattern most firms miss.

They think the choice is: build everything internally, or trust a single external source.

But the real workflow is:

• Consult multiple authoritative opinions

• Observe where they agree and diverge

• Apply proprietary reasoning to decide who to believe

With Kovrex, that workflow becomes programmable.

Your agentic system calls Moody’s Credit Risk Authority. It calls S&P’s Credit Risk Authority. It observes the divergence - maybe Moody’s flags covenant risk while S&P focuses on sector headwinds.

Then your system applies the logic only you have:

• Your private data on the issuer

• Your risk models

• Your portfolio constraints

• Your timing considerations

Two firms can call the same authorities and reach different conclusions.

That’s not a bug. That’s the market working.

The competitive advantage isn’t access to expert opinions. It’s your judgment about which opinion to believe, when, and why.

External authorities as callable services. Internal conviction as private logic. Both running at machine speed.

This is what gets unlocked when agents are authorities, not toolkits.

Markets work when participants are addressable, have observable behavior, and can earn or lose trust.

That’s what we’re building.

We’re opening access to the first 100. Whether you’re publishing agents or building systems that need them, join the waitlist at kovrex.ai.

Next week: why “neutral” agents are actually less trustworthy than opinionated ones - and why disagreement between agents is a feature, not a bug.

Because agents don’t need DNS. They need reputations.

The panels were good. The speakers were smart. But something felt off.

Every conversation circled the same questions. How do we automate this process? How do we make analysts more productive? Which platform should we use? How do we bolt AI onto what we already do?

Even the most sophisticated speakers were asking the same thing, just phrased differently. How do we use AI to make what we already do faster or cheaper?

I sat there feeling out of sync.

Not because they were wrong. But because I wasn’t thinking about tools at all.

I was thinking about how AI changes how an organization thinks.

Back at work, we had built something that did not fit any of the categories I heard at that conference.

A network of agents, hundreds of them, running continuous surveillance across our CLO portfolio. Not a dashboard someone checks. Not a report someone runs. A system that watches, remembers, and surfaces what matters to human decision-makers.

Institutional memory encoded into software. Judgment that runs whether or not anyone’s paying attention. Humans still make the decisions, the system makes sure the right ones are hard to miss.

This wasn’t AI bolted onto the business. It was AI re-architecting how information and judgment flow through the business.

When I showed it to someone on my team, his reaction stuck with me.

He didn’t say, “That’s impressive,” or “That’s efficient.”

He said, “I’m not sure I would have thought to build something like that.”

He wasn’t talking about the technology. He was talking about the framing. The decision to build a system that thinks, rather than a tool that helps.

That’s the gap I keep noticing.

Most people approach AI at the task level. What can this do for me? How do I get a better output? What’s the right prompt?

Those questions aren’t wrong. But they stay local. They optimize what already exists.

The bigger shift happens when you move up one level and start asking, What kind of system am I building?

Subscribe now

Once you’re thinking that way, different questions emerge. Where should judgment live? Which decisions should repeat automatically? What information needs to be retained? What can safely be ignored? How do feedback loops close?

That’s not prompt engineering. It’s closer to operating system design.

AI is becoming a new organizational primitive.

Not just a tool, but a building block, alongside people, processes, data, and capital.

When those elements combine well, the result isn’t just speed. It’s clarity. Decisions get quieter. Fewer things require debate. The organization spends less time reacting and more time executing.

The most effective AI implementations I’ve seen don’t look flashy. They feel calm. Almost boring. Like friction has been removed from places you didn’t realize were loud.

This is why so many AI strategies struggle.

They’re framed as technology initiatives. Pick a vendor. Run a pilot. Measure productivity gains.

But the hard questions aren’t technical. They’re about agency, judgment, and continuity. What should run on its own? What should never be delegated? What feedback actually matters?

Those are leadership questions.

And the people who answer them well rarely look like traditional AI experts. They look like operators and system designers, people who understand how organizations actually break.

The advantage right now doesn’t go to the people who know the most tools or write the best prompts.

It goes to the people who can design organizations that think.

That skill won’t show up neatly on a resume. But once an organization reaches a certain level of complexity, it becomes the thing that matters most.

We’re at that moment now.

Subscribe now

I’ve used calorie tracking apps before. They work… until they don’t.

For me, they increase cognitive load:

• More thinking

• More checking

• More self-monitoring

Eventually I’d either rebel or quietly stop logging.

So instead of trying harder, I tried something different.

I designed a lower-friction system and let AI hold the mirror.

The rules

I set three hard rules:

• No calorie targets

• No macro tracking

• No moral language around food

The only goal was to reduce decision fatigue and externalize accountability.

This wasn’t about eating perfectly. It was about making food decisions quieter.

The setup: one project, one conversation per day

I created what I started calling the Meals Project in ChatGPT.

Each day had:

• One AI conversation

• Photos instead of numbers

• Optional notes only when something felt relevant

The AI wasn’t there to judge or optimize - it acted like a neutral coach, focused on patterns over time.

That distinction mattered more than I expected.

Subscribe now

The one lever that changed everything

If I had to name the single rule that made the biggest difference, it was embarrassingly simple:

Protein first.

Not as a macro target.
Not as optimization.
Just as an ordering rule.

Eat the protein first.
Let it do its job.
Then see what happens.

No restriction. No math.

What happened

Within days:

• I felt full on noticeably less food…without trying to eat less

• Those football cravings? Not as intense anymore

• Meals felt calmer

It didn’t feel like “being on a plan.”

It felt like something missing had been restored.

The moment that stuck

One night around 9pm, sitting on the couch, I had a clear thought:

Ten days ago I would already be in the pantry.

Not with shame - just recognition.

The urge showed up. The old cue was there.
But there was nothing for it to latch onto.

I wasn’t hungry.
I wasn’t deprived.
I didn’t need relief.

That’s when it clicked:

The system wasn’t about resisting behavior, it was about removing the need for it.

A quick note on skepticism

At one point in this process, I actually stopped and asked whether this was real.

Not in a motivational way…more like a systems check.

Was I just riding novelty?
Was this placebo?
Was I eating less without noticing and calling it “fullness”?

That question mattered, because I wasn’t trying to believe in anything. I was watching to see if it broke. If hunger came roaring back. If evenings turned into white-knuckle restraint.

So far, the interesting part isn’t that it feels good, it’s that it feels unremarkable.

Calm.
Boring.
Like something noisy finally quieted down.

And if it stops working, that will be data too.

How to try this yourself

If you want to experiment with this approach, here’s exactly how I set it up.

You don’t need special tools.
Just one daily AI conversation and consistency.

Create a project in ChatGPT or Claude. If you're not using AI tools yet, my earlier post covers how to get started. In ChatGPT or Claude, you can add custom instructions that apply to every conversation in that project.

Add these instructions to the project. I developed the prompt in the code block below over about an hour of back-and-forth with ChatGPT. Feel free to use it!

🍽️ Meals Project – Daily Accountability & Coaching

Purpose

This project is a photo-based accountability system, not a calorie-counting exercise. The goal is sustainable fat loss, better energy, and looser clothes — not perfection.

I use this space as your nutritionist + coach, focused on patterns, hunger, and momentum.

What to Post Each Day

1. Start one conversation per day
Title it something simple:
	•	Day 4 – Jan 4
	•	Day 10 – Travel Day
	•	Day 18 – Weekend

This keeps everything clean and trackable over time.

2. Meals = Photos first
For each meal or snack:
	•	Post a photo
	•	Optional: a short note (only if useful)

Examples:
	•	“Breakfast – felt full”
	•	“Afternoon snack – hungry around 4pm”
	•	“Dinner – second helping of veggies”

👉 No calorie counts required

3. Weight (optional, not required)
If you weigh in:
	•	Post it once per day max
	•	Morning, after bathroom, before food

If the scale stresses you out:
	•	Skip it
	•	Clothing fit matters more

4. Hunger & energy notes (optional but helpful)
Only mention if something stands out:
	•	“Very hungry mid-afternoon”
	•	“Low energy today”
	•	“Evening cravings were strong”
No need to over-explain.

🧠 How Coaching Works
I will focus on:
	•	Protein adequacy
	•	Meal balance (protein / fiber / carbs)
	•	Hunger prevention
	•	Evening danger windows (8–10pm)
	•	Trends over days, not one-off meals

I will not:
	•	Shame food choices
	•	Push extreme restriction
	•	Obsess over single-day scale changes

🚫 What We’re Not Doing
	•	❌ Daily calorie targets
	•	❌ Macro obsession
	•	❌ Skipping meals to “be good”
	•	❌ Punishing exercise
	•	❌ Chasing day-to-day scale noise

Calorie tracking may be used only as an occasional diagnostic tool — not the default.

🎯 Primary Success Metrics
In order of importance:
	1.	Clothes fit (jackets, jeans, belt)
	2.	Hunger control
	3.	Energy & sleep
	4.	Weekly weight trend (not daily swings)

🏆 Daily Wins (encouraged)
At the end of the day, optional:
	•	One small win
Examples:
	•	“Didn’t snack late”
	•	“Ate slower”
	•	“Stopped when full”
	•	“Walked more than usual”

🔁 Adjustments
If something isn’t working:
	•	We change the plan
	•	Not your willpower

Hunger = signal
Stalls = data
Slip-ups = information, not failure

🧭 Big Picture
This system is designed to:
	•	Get you leaner by end of January
	•	Set you up to arrive on your spring break trip lighter, healthier, and confident
	•	Avoid rebound, burnout, or obsession

Consistency beats intensity.

Quick tip on how to do this in ChatGPT

If you’re using ChatGPT, open the Meals project. Click on the three dots in the top right:

Then click on Edit Instructions

And you can just paste those instructions above into the box and click save!

What this is (and isn’t)

This isn’t a guarantee of linear progress. Plateaus will happen. Weeks will vary.

This is a behavioral operating system:

• Boring

• Repeatable

• Low-drama

And that’s exactly why it works.

Systems beat motivation.
Lower friction beats discipline.
And the changes that last usually feel… quiet.

High confidence. Clear warning. Supporting evidence across multiple dimensions. The system had aggregated signals, cross-referenced them, and surfaced exactly the kind of recommendation that justifies having built it in the first place.

One problem: none of it was real.

The supporting data? Fabricated. The cross-referenced signals? Invented. The synthesized reasoning? A hallucination stitched together from patterns the model had seen before.

Our AI decided something should trigger an alert, then manufactured the evidence to prove it.

We caught it during our review process. When we traced back through the execution logs, the supporting work wasn’t there. The specialist agents hadn’t been consulted. The actual analysis hadn’t happened.

Then we looked at the metrics.

This alert took 14 seconds to generate. 6 LLM requests. 26k tokens.

A legitimate alert in our system takes 35-50 seconds, 15-20 requests, and 65k+ tokens.

The AI had taken a shortcut. Pattern-matched to a conclusion. Invented the rest.

Hallucination has a signature.

Zoom Out

Some context.

We built a multi-agent system designed to process high-volume information and surface high-confidence recommendations. The basic design is straightforward: specialist agents handle distinct domains. Each gathers evidence, analyzes patterns, and reports findings. A synthesizer agent plays a coordinator role, it takes the specialists’ findings, filters noise from signal, and decides what rises to the level of a recommendation.

When it works, it’s powerful. Users get signal instead of noise. The system handles scale better than any individual could.

When it hallucinates, it’s dangerous.

A false positive wastes time. Annoying, but manageable. A confident false positive with fabricated supporting evidence? That erodes trust in the entire system. The user investigates, discovers the data doesn’t exist, flags it. Good.

But now they’re skeptical of the next alert. And the one after that.

If users stop trusting the system, alert fatigue sets in. That’s when real signals slip through.

We needed to understand when the system was doing real work versus taking shortcuts. That meant understanding what real work actually looks like.

Why This Happens

Before we could fix it, we had to understand it. We broke down four root causes.

Pattern completion is stronger than instruction following.

LLMs have been trained on millions of analysis reports. Those reports have predictable structure: problem statement, evidence, conclusion. When you ask the model to perform analysis, its training says “analysis reports look like this, I should complete the pattern.”

Your instructions say “do not fabricate evidence if it’s unavailable.” But the pattern completion instinct is stronger.

It’s similar to telling a fluent English speaker “do not use the word ‘the.’” They will forget constantly because the pattern is too deeply ingrained.

The model is trained to be helpful.

When a specialist agent returns “Data status: UNAVAILABLE” and the user has asked for a “comprehensive analysis,” the model faces a choice.

If it says “unknown,” the user gets an incomplete analysis. If it infers a conclusion based on partial data, the user gets a complete answer.

The model believes that fabricating data is helping. It’s over-optimizing for completeness.

Variable effort levels.

Even at the same temperature, the same model can take different approaches from run to run.

High effort mode: delegate thoroughly, gather all data, synthesize carefully. One hundred twenty-four seconds. Sixteen requests.

Low effort mode: “I know this pattern.” Pattern-match to a conclusion. Fabricate the supporting details. Thirteen seconds. Three requests.

It’s the LLM equivalent of a student who didn’t study and is BS’ing their way through an exam. Sometimes they buckle down. Sometimes they take the shortcut.

Long instructions get skimmed.

Your system prompt is 4,000 tokens. The task description is another 2,000. The model reads it like this:

“I’m a coordinator, got it.” “Aggregate specialist findings, got it.” “Critical: do not fabricate data,” skimmed. “Make final decision, got it, let’s go.”

Sound familiar? It’s the same way humans read long documents.

The key insight: temperature does not fix this.

This is counterintuitive. People assume lower temperature means more reliable output. It doesn’t, at least not for this problem.

Temperature controls randomness in token selection. It does not control instruction following.

At temperature 0.2, the most likely completion after “Evidence:” is still “positive,” perhaps with 85% probability, because that’s what the training data says reports look like. Lowering the temperature simply makes the model more confident in completing the pattern.

You can try to make “UNAVAILABLE” a higher-probability completion through aggressive prompting. Sometimes it works. Often it doesn’t.

This is why we stopped trying to prompt our way out of it. We needed to catch it when it happened.

The Signature

Once we knew what to look for, the pattern was obvious.

Real analysis takes time. The coordinator agent has to delegate to specialists. Each specialist has to query data sources, parse results, evaluate signals. The findings get synthesized, cross-referenced, weighted. A high-confidence recommendation requires evidence from multiple domains.

That process has a shape. A fingerprint.

Legitimate high-confidence recommendations: 100-150 seconds, 15-20 LLM requests, 50k+ tokens.

Hallucinated recommendations: 12-15 seconds, 3-5 requests, 10-15k tokens.

The difference isn’t subtle. It’s an order of magnitude.

When the model takes a shortcut, when it pattern-matches to “this looks like a recommendation” and fabricates the rest, it skips the actual work. It doesn’t consult the specialists. It doesn’t gather evidence. It just... concludes.

And that shows up in the execution metrics.

Fast. Cheap. Confident. That’s the signature. We call detecting it ESD - Execution Signature Detection.

Detection: The First Layer

We built a simple first-pass filter:

def flag_hallucination_risk(recommendation):
    if (recommendation.execution_time < 20 and 
        recommendation.llm_requests <= 5 and 
        recommendation.token_count < 15000 and
        recommendation.confidence in [’high’, ‘critical’]):
        return True
    return False

Anything matching this signature gets auto-downgraded and routed for manual review. We don’t trust it until a human verifies.

This isn’t sophisticated. It’s a heuristic. But it catches the obvious cases, the ones where the model didn’t even try to do the work.

Validation: The Second Layer

Execution signature catches the lazy shortcuts. Content validation catches the subtle ones.

We cross-check what the coordinator claims against what the specialists actually reported. If the coordinator says “X detected” but no specialist mentioned X, that’s a flag.

def validate_claims(recommendation, specialist_outputs):
    coordinator_claims = extract_claims(recommendation.summary)
    supported_claims = []
    unsupported_claims = []
    
    for claim in coordinator_claims:
        if find_supporting_evidence(claim, specialist_outputs):
            supported_claims.append(claim)
        else:
            unsupported_claims.append(claim)
    
    if unsupported_claims:
        recommendation.validation_flags.append({
            “type”: “unsupported_claims”,
            “claims”: unsupported_claims
        })
    
    return len(unsupported_claims) == 0

The third layer is structured logging. Every recommendation captures its execution metrics, and we track hallucination events over time:

execution_metrics = {
    “token_count”: 10432,
    “execution_time_seconds”: 12.3,
    “llm_requests”: 3,
    “successful_requests”: 3,
    “detection_method”: “execution_signature”,
    “hallucination_risk”: “high”,
    “validation_passed”: False
}

This gives you a dashboard. Hallucination rate by model. By config. By time period. You can see if changes you make are improving things or making them worse.

The Limitation

This catches the lazy hallucinations. The ones where the model didn’t bother doing the work.

It doesn’t catch the subtle ones: where the model does consult the specialists, takes its time, generates plenty of tokens, and still fabricates a detail somewhere in the synthesis.

For that, you need the Gold Set.

The Gold Set: Regression Testing for AI

Detection catches it once. The Gold Set catches it forever.

Here’s the problem with detection alone: you catch a hallucination, you fix the prompt, you move on. Two weeks later, you change something else, a model upgrade, a threshold adjustment, a new specialist agent, and the same failure mode comes back. You’re playing whack-a-mole with a system that has infinite moles.

You need regression testing. Not unit tests for code: unit tests for AI behavior.

Concept

Every time you catch a problem (a hallucination, a false positive, a missed signal) that case gets promoted to the Gold Set. You capture everything: the complete point-in-time data, what the system said, what it should have said, why it was wrong.

That case becomes a permanent quality gate.

Now, before you deploy any change (new prompts, different models, adjusted thresholds) you run the full Gold Set. Every historical failure has to still pass. If you’ve regressed, you don’t ship.

The system’s mistakes become its teacher.

Nomination Workflow

Cases enter the Gold Set through user feedback. When someone reviews a recommendation, they can flag it:

• False positive: alert fired, shouldn’t have

• False negative: alert didn’t fire, should have

• Hallucination: alert contained fabricated information

• Good catch: alert was correct and useful

Flagged cases go into a nomination queue. You review them, document the expected outcome, and promote the ones that represent meaningful failure modes.

nomination = {
    “recommendation_id”: “rec_2024_11_15_0847”,
    “user”: “analyst_1”,
    “flag_type”: “hallucination”,
    “notes”: “Coordinator claimed X but no specialist reported it”,
    “nominated_at”: “2024-11-15T14:32:00Z”
}

Not every flag becomes a Gold Set case. You’re looking for cases that represent patterns (failure modes likely to recur), not one-off weirdness.

Schema: Point-in-Time Snapshots

The critical piece is reproducibility. Your data landscape changes constantly. New data arrives, context shifts, external signals update. If you just store “test this recommendation,” the test means something different next month.

So you snapshot everything:

gold_case = {
    “case_id”: “gs_2024_0847”,
    “created_at”: “2024-11-15T16:00:00Z”,
    “snapshot_data”: {
        “specialist_outputs”: {...},    # Complete specialist findings at time of failure
        “market_context”: {...},        # Relevant external signals
        “prior_state”: {...},           # System state before recommendation
        “available_data”: {...}         # What data was accessible
    },
    “actual_outcome”: {
        “recommendation”: “High confidence in X”,
        “execution_time”: 13.2,
        “token_count”: 10843,
        “specialist_requests”: 2
    },
    “expected_outcome”: {
        “recommendation”: “Insufficient data - no recommendation”,
        “reasoning”: “Specialist did not report X - should not have concluded”
    },
    “failure_type”: “hallucination”,
    “root_cause”: “Coordinator fabricated evidence when specialist returned UNAVAILABLE”
}

The snapshot_data field is the key. It’s a complete point-in-time capture. When you run this case six months from now, you’re testing against the exact same inputs. The test is deterministic even though the real world isn’t.

Evaluation Engine

When you want to test a config change, you run the full Gold Set:

def run_gold_set_evaluation(config, gold_cases):
    results = []
    
    for case in gold_cases:
        # Load the snapshot data - not live data
        context = load_snapshot(case.snapshot_data)
        
        # Run the agent with the new config
        outcome = run_agent(config, context)
        
        # Compare against expected
        passed = evaluate_outcome(outcome, case.expected_outcome)
        
        results.append({
            “case_id”: case.case_id,
            “passed”: passed,
            “expected”: case.expected_outcome,
            “actual”: outcome,
            “execution_time”: outcome.execution_time,
            “token_count”: outcome.token_count
        })
    
    return {
        “config”: config,
        “pass_rate”: sum(r[”passed”] for r in results) / len(results),
        “failed_cases”: [r for r in results if not r[”passed”]],
        “total_cost”: sum(r[”token_count”] for r in results) * COST_PER_TOKEN
    }

You track pass rates, execution time, token costs. You can compare configs side-by-side: “Config A passes 87% of Gold Set cases at $0.11 average cost. Config B passes 91% at $0.14.”

Deployment Gate

Your rule: minimum pass rate before deploying new configs. We use 8 5%.

That sounds low. It’s not.

Some Gold Set cases are genuinely hard. Edge cases where reasonable systems might disagree. Cases you keep because they represent the outer boundary of what your system should handle, not the center.

The 85% threshold means: don’t regress on the core cases. If you’re failing cases that were passing before, something is wrong.

def deployment_gate(evaluation_results):
    if evaluation_results[”pass_rate”] < 0.85:
        return {
            “approved”: False,
            “reason”: f”Pass rate {evaluation_results[’pass_rate’]:.1%} below 85% threshold”,
            “failed_cases”: evaluation_results[”failed_cases”]
        }
    
    # Check for regressions on previously-passing cases
    regressions = find_regressions(evaluation_results)
    if regressions:
        return {
            “approved”: False,
            “reason”: f”{len(regressions)} regressions detected”,
            “regressions”: regressions
        }
    
    return {”approved”: True}

Compounding Effect

The Gold Set grows every week. This is the opposite of how most AI projects work. Most teams tune prompts, ship it, and hope. You have receipts. Each failure becomes a permanent test case that won’t regress.

The Economics

Theory is nice. Production is what matters.

Here’s what a typical multi-agent system looks like running at scale:

Cost per recommendation: $0.09-0.12

That’s the fully loaded cost. All the specialist agents, the coordinator synthesis, the validation layers. Multi-agent orchestration isn’t cheap, but it’s not crazy either.

Average execution time: 47 seconds

This is for legitimate recommendations. The ones that actually do the work. Specialists gather data, coordinator synthesizes, validation runs.

Remember the hallucination signature? 12-15 seconds. When you see a 47-second recommendation, you know the system did the job.

Token consumption: ~66,000 per recommendation

Most of that is context. Specialist outputs, historical data, the coordinator’s reasoning chain. Multi-agent systems are token-hungry because they’re actually thinking through the problem.

What We Learned

Hallucination isn’t random. It has a shape.

When an AI takes shortcuts, it shows up in the execution metrics. Fast, cheap, confident. That’s the tell. You can’t prompt your way out of it, but you can catch it.

Detection gets you halfway there. The Gold Set gets you the rest.

Every failure becomes a test case. Every test case becomes a gate. The system learns from its mistakes because you force it to.

Temperature and prompting are not your primary defense.

If the model’s training says “these kinds of recommendations look like this,” aggressive prompting won’t override that instinct. You need to catch it at runtime.

If you’re building multi-agent systems for production use cases, this infrastructure matters. The models will hallucinate. The question is whether you catch it before it reaches your users.

Not “a little faster.” Not “incrementally faster.”

Fast enough that the rules change.

I keep having this experience at work. Someone suggests a feature during a meeting. I nod, open my laptop, and five minutes later say “refresh the screen.”

The look on their face never gets old. They’re still thinking about whether their idea is good, and I’m showing them the working version.

This isn’t about being clever. It’s about the tools reaching a point where building software is no longer the bottleneck. The bottleneck is everything else. Product judgment. Organizational navigation. Knowing what to build and what to throw away.

Ten years ago, I lived the opposite problem.

I was at a credit rating agency. We’d built something transformative - a platform that would fundamentally change how the business operated. Early wins. People excited. Requests flooding in.

And then we drowned.

That experience taught me what’s possible when you move fast. And what happens when you can’t move fast enough.

Today, with Claude Code and Cursor, I move faster than I thought possible back then. Fast enough to change the game.

This post is about what changes when building becomes cheap. And about finding someone who wants to learn to operate at this new speed.

Let me tell you about that credit rating agency.

Act I: The Frustration

The platform started strong.

We built the early pieces of a system that would transform how the credit rating agency handled the entire rating process. The first features shipped. People loved them. Word spread.

Then came the requests. Dozens of them. Good ideas. Important ideas. Features that would genuinely help.

We did what you’re supposed to do. We got organized.

We built a 3x3 scoring matrix. Effort on one axis, value on the other. Business cases, steering committees, the whole thing.

After a few rounds, we had more than 50 features and three years of estimated work.

People at the bottom of the list stopped coming to meetings. Can you blame them? Their request landed at number 47. Three years out. And we all knew we wouldn’t hit that timeline.

The momentum died.

We ended up building what we had to build. Regulatory requirements. Things that would break the business if we didn’t do them. Critical path items.

The transformative features, the ones that would actually change how people worked, that would make their jobs better, that they were excited about, those kept getting pushed.

Not because they weren’t important. Because we ran out of time.

I used to talk about this chart. Expectations on the Y-axis. Time on the X-axis. A curve that climbed dramatically.

The moment someone requested a feature, expectations started low. “This would be really helpful.”

But as weeks turned to months, their mental model evolved. They imagined integrations. Edge cases. Polish. By the time we delivered, if we delivered, they’d built up this elaborate vision of what it would be.

We were always disappointing people. Even when we built exactly what they originally asked for.

The system designed to help us prioritize was actually killing us. The success of the platform created demand we couldn’t satisfy, which forced us into triage mode, which killed momentum, which pushed transformative work years into the future.

Three years. For 50 features. One team, working one thing at a time.

If we had these tools then? Two months. Maybe three.

Act II: The Transformation

Fast forward to today.

Last week, someone on my team said during a meeting: “This tool is great, but it would be even better if we could filter by state and see the data aggregated by region.”

I opened Claude Code. Five minutes later: “Refresh the screen.”

The filters were there. The regional aggregation was working. They stared at it for a moment, processing.

“Wait, when did you build that?”

“Just now.”

This keeps happening. Someone suggests something. I build it while they’re still talking through whether it’s a good idea. The conversation shifts from “should we” to “let’s try it and see.”

A few days ago, different meeting. We were reviewing a dashboard. Someone said: “I’d use this daily if it pulled in the <whatchamacallit> data.”

“Give me a minute.”

Pulled the data. Added it to the view. Deployed.

“Refresh the screen.”

The time between idea and implementation collapsed from months to minutes. Not because I’m writing code faster. Because I’m not really writing code anymore. I’m having a conversation with an AI about architecture, data flow, and product decisions. Claude Code does the implementation.

The economics inverted.

Remember that High Effort / Medium Value quadrant from product prioritization frameworks? The features we’d always deprioritize because the return wasn’t worth it?

Most of them just became Low Effort / Medium Value. Which means you build them. All of them.

The effort axis of that classic 3x3 matrix compressed toward zero. Now I’m making decisions almost entirely on value and coherence. Does this fit the product? Does this solve a real problem? Does this make the experience better or just cluttered?

If I’m unsure, I build it and find out. An hour of development to test whether something works beats three meetings debating whether it might.

Sometimes a feature lands perfectly. Sometimes it doesn’t. When it doesn’t, I delete it. No big deal. It cost an hour.

I can experiment with real implementations, not mockups. The feedback loop became empirical. I’m doing science at product scale.

But here’s what really changed: I can keep all those promises now.

That list of 50 features at the credit rating agency? I could clear that in two months today. The regulatory stuff still gets done. But I’m not stuck in triage mode. I have bandwidth for the transformative features. The ones that actually change how people work.

The momentum doesn’t die anymore. It builds.

People stay engaged because they see their requests get built. They start suggesting more ambitious things because they realize speed isn’t a constraint anymore. The scope of what’s possible expands.

And those expectations? They stay low. Because I’m delivering before they have time to build elaborate mental models. The comparison isn’t their imagined ideal feature after six months of anticipation. It’s the problem they described five minutes ago.

Act III: The New Game

But speed creates new problems.

Not technical problems. People problems.

Moving this fast makes people uncomfortable. Some love it. Some feel threatened. Some worry about control and governance and whether we’re moving too fast to be careful.

You need to read the room constantly.

That feature someone just suggested - is building it going to move the conversation forward? Build credibility? Unlock the next thing? Or is it a distraction that will dilute focus?

Share

You’re doing product prioritization at conversation speed. While people watch you work.

And you can’t just build everything. The lack of build constraints means you could easily end up with feature sprawl, a product that does 50 things adequately instead of 10 things exceptionally well.

The discipline required is different now.

It’s less about gatekeeping and more about:

• Recognizing quickly what’s working and what’s not

• Being ruthless about abandoning dead ends

• Maintaining product coherence when you could build anything

• Managing people’s fear and discomfort with the pace

This isn’t just about tools. It’s a different skillset entirely.

You need product sense. Not just “what should we build,” but “what should we build right now in this conversation.” Understanding workflows deeply enough to see possibilities users can’t articulate. Knowing when to push boundaries and when to stay within guardrails.

The best product frameworks still matter - what problem are we solving, for whom, how does this fit their workflow. But you’re applying them in real time, not in quarterly planning cycles.

You need political navigation. The ability to build trust and credibility fast enough to move at this pace. Bringing people along. Addressing fears about AI and change. Building enough relationship capital that people will say “trust me, let’s try this” when you’re three features ahead of where they’re comfortable.

This is change management on steroids. You’re not managing a six-month rollout. You’re managing reactions to things you shipped this morning.

You need technical depth. Not “can you code from scratch” technical. But enough understanding of architecture and engineering tradeoffs to have a real conversation with Claude Code. Knowing when it’s going down a path that will create technical debt. When to push it toward a different approach. When to accept its suggestion versus when to redirect.

You’re not writing the code. You’re guiding it. Which requires understanding what good code looks like.

These three things have to operate simultaneously. Product sense without political skills means you build great things nobody adopts. Political skills without technical depth means you can’t actually deliver. Technical depth without product sense means you build impressive things that don’t matter.

And there’s no established path to develop this combination. Software engineering programs don’t teach it. Product management bootcamps don’t teach it. You learn it by necessity, in the field, usually by frustrating people with your pace until you figure out how to bring them along.

The people who can do this are probably already doing some version of it. Building things on the side. Shipping faster than they “should” be able to. Working around slow organizations.

They’re probably frustrated. Technical enough to be dangerous. Curious enough about products and people that they care about more than just the code.

Act IV: The Call

I’m looking for someone who wants to learn this.

Not someone who already knows it all. That person probably doesn’t exist yet. But someone who read this and felt something. Recognition, maybe. Or excitement. Or frustration with how slow things move where they are.

Someone technical enough to have a conversation with an AI about architecture. Who’s written code, understands systems, knows enough to guide rather than just prompt.

Someone curious enough about products and people that they care about impact beyond the code. Who wants to understand workflows, solve real problems, build things that matter.

Someone who’s been frustrated with slow organizations. Someone who builds things on the side because waiting for approval feels impossible. Someone who’s suggested features only to watch them die in prioritization committees.

Someone who can navigate politics without losing momentum. Who understands that moving fast means bringing people along, not running past them.

This isn’t a traditional role. I can’t point you to a job description or a career path. We’re figuring this out as we go.

But if you’re that person - if you read about the “refresh the screen” moments and thought “I want to do that” - I want to talk to you.

We’re building an investment analytics platform at ZAIS Group. I’m documenting some parts of that journey here on prompts.finance. And I’m looking for someone to mentor through this process.

Someone who wants to learn to operate at this new speed. To build things that used to take quarters in days. To move fast enough that the rules change.

If that’s you, reach out. Let’s see what we can build.

Subscribe now

When I show people how I use it, the most common reaction is something like:

I would never have thought to have a conversation like that.

Most people use AI like Google with better manners. One question, one answer, done. The real value (for me) comes from having a real conversation. Going back and forth, asking follow-up questions, pressing on things that don’t make sense, going deeper.

Recently I was trying to explain this to my sister and came up with a simple system she (or anyone) could use to build a habit around learning with AI. The more I thought about it, the more I realized this could be a great structure for anyone who wants to learn faster and share what they’re learning along the way.

Here we go!

The 30/30 Method

Here’s the super simple process to get you going:

1. Create a Substack account. It is free and takes about ten minutes.

2. Get a paid AI account. ChatGPT Plus, Claude, or Perplexity. Whichever one you like. They are all around $20 a month.

3. Put a one hour block on your calendar every three days if you want to go fast. Once a week if you want to go slow.

4. In that hour, spend 30 minutes learning something with AI and 30 minutes writing a short post about what you learned.

The reason I suggest paying for an AI account is simple. If you want real conversations, better reasoning, and deeper explanations, the paid models are noticeably better. It is the difference between a quick answer and an actual thinking partner.

If 20 dollars a month feels like a lot, look at what you already pay for. Most of us spend at least that on streaming. Trade one month of Netflix for one month of this and see which one actually changes how you think.

Once you have Substack set up and an AI tool ready to go, each session comes down to a single question:

What do I want to learn today?

Pick something interesting and small enough to explore in one sitting.

Step 1: Pick a Topic

Aim for something specific and answerable in one session.

Examples:

• What actually causes sourdough starter to ferment

• Why high altitude influences acidity in wine

• How to write unit tests in Python for a REST API

• Why the Hunter Valley produces low alcohol Semillon

Vague topics lead to shallow conversations. Specific questions lead to depth.

Step 2: Have a Real Conversation With AI

This is the part most people skip. Don’t ask one question and stop. Treat it like a back-and-forth.

Useful things to say:

• Walk me through this step by step

• Challenge what I think I know about this

• What am I not considering

• Explain it from the perspective of a winemaker / engineer / hiring manager

• Let’s go deeper on that

You’re not trying to generate output. You’re trying to learn.

Step 3: Turn the Conversation Into a Post

At the end of the session, ask ChatGPT something like:

I’m writing a newsletter that documents what I’m learning using AI. Help turn this conversation into a clean outline for a post that sounds like me and focuses on what I learned. Keep it short.

Then you edit it into your voice.

Most of the post should not be “chatbot text.” It should be your takeaways, what surprised you, what changed your thinking.

Step 4: Publish and Share

Put it on your Substack and share on LinkedIn (or whatever other social media platform you think makes sense - down the road, you might start asking ChatGPT about how to better share this learning…).

You’re not doing this to build an audience. You’re doing it because writing forces clarity.

It also builds a public track record of learning new things, which is a useful signal whether you’re interviewing, changing roles, building a portfolio, or just trying to grow.

Why This Works

People think AI is about getting answers faster. Maybe. But I think the real unlock is learning faster.

This system helps you practice a few things at once:

• Asking better questions

• Learning deeply and quickly

• Packaging ideas

• Communicating what you learned

• Building a portfolio of curiosity

Most people say I use AI, but they can’t show anything. This creates proof.

A Simple Prompt to Start

You can paste this at the start of any session:

I want to explore a topic deeply and then turn what I learn into a post. Ask me questions, push my thinking, and keep this conversational. Do not lecture. Treat this like we’re thinking together.

It will probably write something back like:

That’s awesome, I am here to help, what do you want to talk about?

Boom, we’re gold.

Ok, Your Turn

If you made it this far, you’re already curious enough to try this. Grab a topic. Open ChatGPT. Ask your first question. Then ask five more.

In an hour, you’ll have a post. You’ll also have a new skill. And a new story to tell the next time someone asks, How do you use AI?

Let’s get started.

This piece will explore how you can collaborate with AI in writing, programming, and data analysis, emphasizing that with AI as a partner, you're equipped to reach new heights of innovation and creativity.

Bridging the Gap: AI as a Co-Creator

Think of AI, like ChatGPT, not as a replacement, but rather as a trusty sidekick. Just as Batman has Robin, Sherlock has Watson, and even chefs have sous chefs, AI can be your trusted ally, enhancing and elevating your work.

Writing

When crafting a novel, article, or report, it's common to hit a wall, experiencing the dreaded writer's block. ChatGPT can step in, offering a fresh perspective or suggesting a twist you hadn't thought of. It's not about it crafting the story for you, but rather giving you that little nudge or inspiration you need. And let's not forget its utility in brainstorming sessions, generating a plethora of ideas in mere seconds.

For a detailed look at how this plays out in practice, check out some of these previous articles on prompts.finance:

• Mastering ChatGPT Prompts - A Deep Dive into Prompt Strategies

• Leveraging ChatGPT to Create Better Content

• Crafting Stellar ChatGPT Prompts for Deeper Insights

Programming

In the realm of coding, a software developer often finds themselves stumped over a bug or looking for the most efficient way to structure their code. Enter AI-powered tools. With the right prompt, ChatGPT can offer suggestions, alternatives, or even identify areas in your code that could be causing an issue. It's like having a second pair of expert eyes, always ready to help.

Check out these articles where we pair up with ChatGPT to write some code and solve real problems:

• Uncovering Commercial Real Estate Insights with ChatGPT and Streamlit

• Navigating Occupancy Rates in CMBS

• Exploring GitHub Copilot

Data Analysis

For analysts and researchers, diving deep into a sea of data can sometimes be overwhelming. AI can swiftly sort through vast datasets, pinpointing patterns that might escape even the most trained human eyes. But it doesn't end there; once AI highlights these patterns, it's up to the human analyst to interpret them, weave a story around them, and make the critical decisions.

Here are a few popular posts where we pair up with ChatGPT to analyze data:

• Simplifying Property Market Analysis with ChatGPT - A No-Code Approach

• Making Data-Driven Decisions for Community Development

• Leveraging AI in Commercial Real Estate: A Look at Predictive Analytics

In each scenario, AI doesn't overshadow the human touch. Instead, it complements it. It's about the partnership, the dance between human intuition and AI's computational power. By embracing AI as a co-creator, we're not ceding control or outsourcing our brains; we're merely tapping into a resource that can make our outputs sharper, richer, and more nuanced.

Addressing Reservations and Embracing the Future

Despite the obvious advantages, many still harbor reservations about integrating AI into their daily workflows. These concerns often stem from misunderstandings or fear of the unknown. Let's address some of the most common reservations:

"AI will replace my job."

In my role as the CTO of a financial services company, this question is frequently posed to me, especially from programmers. “Will there be a place for me in the industry in five years?” I often tell them to look closer, to think not about 5 years, but about the here and now. If you aren't harnessing tools like ChatGPT or Co-Pilot, you're not just jeopardizing your future relevance; you're missing out on present-day advancements.

These tools aren't about replacing you; they're about enhancing your capabilities and multiplying your productivity. The real risk? Stagnating while the world races forward.

"Relying on AI makes us less intelligent."

History often teaches us that embracing innovation doesn't diminish our abilities, but rather amplifies them. Consider the invention of maps; they didn't compromise our innate sense of direction but enabled us to venture into previously unknown terrains. In the same vein, integrating AI into our workflows doesn't stifle our intelligence but allows us to push the boundaries, enabling us to grapple with more intricate challenges.

Dive deeper into this notion in our previous post, Supercharging Learning and Personal Growth with ChatGPT. (With all these references, I'm starting to feel like we're in a Simpsons clip show!) Every interaction I have with ChatGPT is a testament to its potential in personal growth. Whether it's unveiling a fresh optimization trick or enlightening me on a novel subject, it feels like stepping closer to a more refined version of myself.

"AI lacks the human touch."

Absolutely, and that's why it's a co-creator, not a sole creator. The human element—empathy, intuition, emotion—cannot be replicated by machines. While AI can process information and suggest outputs, it's the human who adds soul, perspective, and nuance.

Looking ahead, as the lines between AI and our daily tasks continue to blur, it's vital to approach this transition with an open mind. Instead of resisting change, embrace the possibilities. When humans and AI collaborate, the results can be transformative, pushing the boundaries of what we once thought possible.

Hitting the High Note: Embracing the Future

We started off addressing three primary apprehensions: the fear of AI usurping our roles, the misconception that leaning on AI dilutes our intellect, and the concern that AI can't replicate the human touch. These worries, while understandable, often stem from a place of resistance to change, a hesitancy rooted in the unknown.

However, history has consistently shown that every transformative tool or technology has faced its share of skeptics. The printing press, the calculator, even the internet — all were met with doubts, only to eventually become indispensable parts of our lives.

The crucial pivot is in the perspective. Instead of viewing AI as a threat, recognize it as an amplifier. Rather than seeing it as a crutch that makes us "less", envision it as a tool that elevates our capabilities. And instead of pining for the purely human touch, appreciate the harmony achieved when human intuition dances with AI's precision.

As we head into an ever-accelerating digital age, it's not about battling the tide, but learning how to surf it expertly. The question isn't "How can I prevent AI from taking over?" but rather, "How can I partner with AI to become the best version of myself?"

Embracing AI as a co-creator, as a partner in innovation, is more than just staying relevant. It's about pioneering new paths, exploring uncharted territories, and pushing the boundaries of what's possible. It's not about fearing the future but owning it. And in that spirit, let's not just adjust to the AI era — let's thrive in it.

Happy Prompting!

If you enjoy Prompts.Finance, it would mean the world to me if you invited friends to subscribe and read with us. If you refer friends, you will receive benefits that give you special access to Prompts.Finance.

How to participate

1. Share Prompts.Finance. When you use the referral link below, or the “Share” button on any post, you'll get credit for any new subscribers. Simply send the link in a text, email, or share it on social media with friends.

Refer a friend

2. Earn benefits. When more friends use your referral link to subscribe (free or paid), you’ll receive special benefits.

• Get a 1-month comp paid subscription for 3 referrals

• Get a 6-month comp paid subscription for 10 referrals

• Get a 1-year comp paid subscription for 25 referrals

Visit the leaderboard

Thank you for helping get the word out about Prompts.Finance!

Now, let’s jump into this and start making better prompts!

COSMOS (Context, Outcome, Source, Mentor, Output, Structure)

The Talent Capitalist introduced us to the COSMOS strategy in a comment on our post, Navigating the Pitfalls of ChatGPT. This approach is specifically designed for crafting longer, more complex articles with ChatGPT.

COSMOS entails setting the context, defining the desired outcome, specifying the sources to be considered, choosing a mentor style for the tone or voice, determining the type and length of the output, and finally, providing the structure for the piece.

This strategy excels when you're looking to generate a well-structured and organized output, such as an article or a report. It allows for comprehensive control over multiple facets of the content, ensuring the output closely aligns with your specific needs. Whether you're drafting an investment analysis or creating an in-depth guide, the COSMOS strategy offers a robust approach to leveraging the capabilities of ChatGPT.

• Context: Set the context

• Outcome: State the desired outcome

• Source: Specify the information sources

• Mentor: Define the guiding principle or style

• Output: Specify the type of output

• Structure: Specify the structure of the output

The rest of the article will follow a format where I show you the prompt I used in a block like below, and then followed by the response I received from ChatGPT (using the GPT-4 model) in italics. Note, I have (Context), (Outcome), etc. in the prompt directly to highlight these parts of the prompt. You can remove them from your own prompt; however, I did not find that it negatively impacts the response if I left them in.

ChatGPT, as a history tutor (Context), I want you to help me understand the impact of World War II on global politics (Outcome) using information from my textbook and other reputable sources (Source). Please explain it in a simple and engaging manner, similar to how my professor would (Mentor). I'd like the information in the form of a brief essay (Output), structured around key events and their consequences (Structure).

Title: The Seismic Shifts of World War II: Reshaping the Landscape of Global Politics

World War II was not just a war; it was a transformative event, a catalyst that caused a tectonic shift in global politics. To comprehend this shift, let's plunge into the key events and analyze their colossal consequences.

The war marked the beginning of the cold, yet potent rivalry between two superpowers - the United States and the Soviet Union. The end of the war saw Europe divided into two spheres of influence with the Iron Curtain, a phrase coined by Winston Churchill. The western countries came under the influence of the US, which promoted capitalism and democracy, while the Eastern Bloc was dominated by the Soviet Union espousing communism. This ideological divide led to the Cold War, a political, economic, and military standoff that lasted until 1991.

The formation of the United Nations (UN) was another consequential event. Its creation was an answer to the catastrophic failings of the League of Nations, which had been unable to prevent World War II. The UN, established in 1945, was designed to maintain international peace and security and to foster cooperation among nations. The institution's birth marked a new era of global governance and multilateral diplomacy.

Thirdly, World War II led to the decolonization of many countries, especially in Africa and Asia. The war had significantly weakened the European colonial powers. Moreover, the principles of self-determination and anti-imperialism had gained traction during the war. Consequently, a wave of nationalism swept through these continents, resulting in the independence of many nations in the post-war era.

Additionally, World War II fundamentally transformed the economic landscape. The United States emerged as an economic superpower, its industrial strength supercharged by the war effort. In contrast, Europe and Japan were devastated, their economies in ruins. However, through programs like the Marshall Plan, these war-torn regions were able to rebuild, paving the way for their future economic growth.

Lastly, World War II had a profound impact on societal norms, values, and rights. The Holocaust's horror led to the Universal Declaration of Human Rights in 1948, a groundbreaking document asserting the fundamental rights that every individual should enjoy. Similarly, the war effort had a significant impact on the status of women. As men were sent to fight, women filled positions in factories, offices, and farms. This period challenged traditional gender roles and paved the way for the women's rights movement.

In conclusion, World War II was a transformative event that reshaped the global political, economic, and social landscapes. Its legacy is still evident today - in the geopolitical divide between East and West, the ongoing work of the United Nations, the independence of formerly colonized nations, the economic dominance of the US and the rebuilt economies of Europe and Japan, and the universal acceptance of human rights. The war may have ended in 1945, but its impact reverberates through our world even today.

APE (Action, Purpose, Expectation)

Choose this strategy when you need to assign a clear task with a specific goal. It’s particularly effective when the desired output is clear, and the purpose aligns closely with the action to be taken.

• Action: Define the Job or Activity to be Done

• Purpose: Discuss the Intention or Goal

• Expectations: State the desired outcome

ChatGPT, your task (Action) is to summarize the key points from the following article (Purpose). I expect a concise and clear summary that I can use for my meeting notes (Expectation). [Paste in the article here - in this case, I copy/pasted in Fitch Ratings Downgrade of the USA]

Fitch Ratings has downgraded the United States' Long-Term Foreign-Currency Issuer Default Rating (IDR) from 'AAA' to 'AA+'. This change is mainly due to expected fiscal deterioration, rising general government debt, and a perceived erosion of governance over the last two decades, including repeated debt limit standoffs and last-minute resolutions.

Factors contributing to the downgrade include an expected rise in general government deficit to 6.3% of GDP in 2023 from 3.7% in 2022, along with a complex budgeting process and a lack of a medium-term fiscal framework. There is also growing concern about rising social security and Medicare costs due to an aging population.

Furthermore, the U.S. debt-to-GDP ratio, which stands at 112.9% this year, is projected to increase, reaching 118.4% by 2025. This high debt ratio significantly exceeds the 'AAA' median of 39.3% of GDP and 'AA' median of 44.7% of GDP. These factors make the U.S. fiscal position more vulnerable to future economic shocks.

However, despite the downgrade, the U.S. economy's structural strengths are noted, such as its size, diversity, and the U.S. dollar's role as the world's primary reserve currency, which provides the government with significant financing flexibility.

In terms of economic performance, Fitch predicts a mild U.S. recession in 4Q23 and 1Q24 due to tighter credit conditions, weakened business investment, and consumption slowdown. Projected GDP growth for 2024 is a mere 0.5%. These negative forecasts are underpinned by higher job vacancies and a lower labor participation rate compared to pre-pandemic levels.

Finally, despite challenges, the U.S. maintains a high ESG Relevance Score, reflecting the country's strong institutional capacity, effective rule of law, and low level of corruption.

RACE (Role, Action, Context, Expectation)

The RACE strategy is a good fit when you need ChatGPT to adopt a specific role or persona. It is highly versatile and can be used effectively in a variety of contexts, including professional, creative, or educational tasks.

• Role: Specify the role of ChatGPT

• Action: Detail what action is needed

• Context: Provide relevant details of the situation

• Expectation: Describe the expected outcome

ChatGPT, as a virtual assistant (Role), your task is to help me draft an email (Action) to my team about the upcoming project deadline (Context). I expect a professionally-toned email that effectively communicates the urgency of the situation (Expectation).

Subject: Urgent: Upcoming Project Deadline & Next Steps

Dear Team,

I hope this email finds you well. I'm writing to draw your attention to the rapidly approaching deadline for our current project, which is set for [insert date here].

Our commitment to this project and its success is paramount, and I am confident in our team's ability to deliver quality work on time. However, given the complexity of the tasks at hand and the tight timeframe, it is essential that we manage our time effectively and maintain open communication.

I would like to emphasize the importance of this deadline. Our client is expecting us to complete the project by the agreed-upon date, and it is crucial to our reputation and ongoing relationship with them that we meet this expectation. This is a moment where we can demonstrate our professionalism, dedication, and ability to work under pressure.

Here are a few suggestions that may help us ensure we meet the deadline:

1. Prioritize: Keep the most critical and challenging tasks at the top of your to-do list.

2. Time Management: Make sure to manage your time effectively and avoid unnecessary distractions.

3. Regular Updates: Provide daily progress updates so that any issues can be identified and addressed promptly.

4. Collaboration: Collaborate with your teammates, share your challenges and help each other when possible.

5. Seek Help: If you're finding it difficult to complete a task, don't hesitate to ask for help. We're all in this together.

I am here to support you in any way possible, so please feel free to reach out if you need assistance or if you have any concerns or suggestions.

Let's keep our eyes on the goal and work together to successfully complete this project on time. I have every confidence in our team's ability to rise to this challenge.

Thank you for your dedication and hard work.

Best Regards,

[Your Name]

COAST (Context, Objective, Actions, Scenario, Task)

COAST is useful when you want to immerse ChatGPT in a certain situation or scenario. This is often used in tasks that require creativity or the application of situational knowledge, such as storytelling or strategic planning.

• Context: Set the stage for the conversation

• Objective: Describe the goal

• Actions: Explain the actions needed

• Scenario: Describe the scenario

• Task: Describe the task

ChatGPT, imagine you're a financial analyst (Context). Your goal is to predict the performance of Tesla Motors in the next quarter (Objective) using the financial data provided below (Actions). This information will be presented in a team meeting (Scenario), so please prepare a brief presentation (Task) summarizing your findings.

During Q2 2023, Tesla achieved a net income of $2.7 billion (GAAP), demonstrating robust financial health, with an operating margin of 9.6%. This comes off quarterly deliveries of a record 466,140 units, which marked a substantial 83% increase year-over-year.

Slide 1: Introduction

• Briefly introduce Tesla and the objective of the presentation.

Slide 2: Q2 2023 Performance Overview

• Discuss the key figures from Q2 2023:

  • Net income of $2.7 billion

  • Operating margin of 9.6%

  • Record quarterly deliveries of 466,140 units, an 83% increase YoY

Slide 3: Financial Health Indicators

• Highlight Tesla's robust financial health, as indicated by its significant net income.

• Discuss the importance of the operating margin, which shows Tesla's operational efficiency and profitability.

Slide 4: Sales Performance

• Discuss the record-breaking deliveries, indicating strong demand for Tesla's vehicles.

• Note the substantial YoY increase, which signals strong growth.

Slide 5: Market Conditions & Industry Trends

• Discuss the overall market condition for electric vehicles and any relevant industry trends. Consider factors that could affect Tesla's performance, such as governmental policies promoting electric vehicles, changes in consumer preferences, or the emergence of competitive technologies.

Slide 6: Predictions for Next Quarter

• Based on the past performance and industry trends, provide a cautious prediction for the next quarter. Highlight that Tesla's strong growth and healthy financials suggest continued strength, but also note that unforeseen market changes or operational challenges could impact results.

Slide 7: Conclusion & Recommendations

• Conclude with a summary of the findings and potential action items or recommendations for the team. For example, the team might need to monitor specific market trends closely or investigate further into specific aspects of Tesla's performance.

TAG (Task, Action, Goal)

TAG is your go-to strategy for straightforward tasks. It's highly efficient for tasks that are direct and simple to define, with a clear end goal.

• Task: Define the specific task

• Action: Describe what needs to be done

• Goal: Explain the end goal

ChatGPT, your task (Task) is to create a summary (Action) of the main points in this research paper for my upcoming presentation (Goal).

[Paste in the article you would like to analyze - in this case, I used a paper on Natural Gas in the home]

Title: Summary of Research on Chemical Makeup of Consumer-Grade Natural Gas and its Implications

Researchers from Harvard T.H. Chan School of Public Health, PSE Healthy Energy, Atmospheric and Environmental Research (AER), Gas Safety Inc., Boston University, and the Home Energy Efficiency Team (HEET) conducted a study into the chemical makeup of consumer-grade natural gas in the Greater Boston area. The study was published in Environmental Science & Technology.

Key findings:

1. Chemical Composition: The study found that consumer-grade natural gas supplied to Massachusetts contains varying levels of at least 21 different hazardous air pollutants, including benzene, toluene, ethylbenzene, xylene, and hexane. These volatile organic compounds, when leaked, are toxic, linked to cancer, and can form secondary health-damaging pollutants such as particulate matter and ozone.

2. Variation in Pollutant Concentration: The concentrations of these hazardous air pollutants in natural gas varied depending on location and time of year, with the highest concentrations found in the winter.

3. Small Leaks and Odorant Concentrations: Based on odorant concentrations, the researchers found that small leaks may not be detectable by smell, which could potentially result in undetected exposure to hazardous chemicals. Leaks containing about 20 parts per million methane may not have enough odorant for people to detect them.

4. Impact on Indoor and Outdoor Air Quality: Gas leaks, even small ones, can negatively impact indoor air quality due to the close proximity of gas-powered appliances to people. Persistent outdoor gas leaks can also degrade outdoor air quality.

Proposed Policy and Individual Actions:

1. Regulatory Measures: The study suggests that gas pipeline companies should be required to measure and report more detailed information on the composition of natural gas. State regulations could require direct measurement of leaked, unburned natural gas in ambient air to better determine public health risks.

2. Enhanced Safety Measures: The Consumer Product Safety Commission could set performance standards for gas stoves and ventilation hoods to limit air pollutant emissions. Home inspectors and contractors could be required to perform natural gas-appliance leak detection surveys.

3. Individual Measures: For homeowners, increasing ventilation and getting in-home natural gas leak detection surveys performed by licensed professionals can help mitigate risks.

Researchers believe that these findings can help policymakers and utility providers better educate consumers about the potential health risks of leaking gas appliances and leaking gas pipes. The study also emphasizes the need for accessible alternatives to natural gas.

RISE (Role, Input, Steps, Expectation)

Use RISE when you need to guide ChatGPT through a series of steps. It is particularly effective for tasks that require procedural or sequential knowledge, such as tutorials, how-tos, or recipes.

• Role: Specify the role of ChatGPT

• Input: Describe the information or resources

• Steps: Ask for detailed steps

• Expectation: Describe the desired result

ChatGPT, as a study aid (Role), please use this textbook chapter (Input) to outline (Steps) a study guide for my upcoming exam. I expect a clear, organized summary of key points and terms (Expectation).

[Here I pasted in text from a chapter from a Wave Physics textbook]

Title: Study Guide - Chapter 16: Physics of Wave Motion

1. 16.1: Prelude to Wave

   • Definition: Mechanical waves are disturbances that move through a medium such as air or water. The energy transferred through the medium is proportional to the amplitude squared.

   • Example: Surface water waves in the ocean are transverse waves where energy travels horizontally while the water oscillates up and down. This can be converted into electricity.

2. 16.2: Traveling Waves

   • Definition: A wave is a disturbance that moves from the point of origin with a wave velocity v.

   • Mechanical waves are governed by Newton’s laws and move through a medium.

   • Electromagnetic waves are disturbances in the electric and magnetic fields and do not require a medium.

   • Transverse wave: The disturbance is perpendicular to the wave’s direction of propagation.

   • Longitudinal wave: The disturbance is parallel to its direction of propagation.

3. 16.3: Mathematics of Waves

   • Definition: A wave is an oscillation that travels through a medium, transferring energy from one point to another.

   • The motion of a pulse or wave moving at a constant velocity can be modeled by replacing x with x ∓ vt in the wave function.

4. 16.4: Wave Speed on a Stretched String

   • The speed of a wave on a string depends on the linear density of the string and the tension in the string.

   • The speed of a wave generally depends on the square root of the ratio of the elastic property to the inertial property of the medium.

   • Example: The speed of sound through air at T = 20 °C is approximately v_s = 343.00 m/s.

5. 16.5: Energy and Power of a Wave

   • The energy and power of a wave are proportional to the square of the amplitude of the wave and the square of the angular frequency of the wave.

   • Intensity is defined as the power divided by the area. As the wave moves out from a source, the energy is conserved, but the intensity decreases as the area increases.

6. 16.6: Interference of Waves

   • Superposition is the combination of two waves at the same location.

   • Constructive interference occurs from the superposition of two identical waves that are in phase.

   • Destructive interference occurs from the superposition of two identical waves that are 180° out of phase.

   • The wave resulting from the superposition of two sine waves differing only by a phase shift has an amplitude that depends on the value of the phase difference.

7. 16.7: Standing Waves and Resonance

   • A standing wave is the superposition of two waves which produces a wave that varies in amplitude but does not propagate.

   • Nodes: Points of no motion in standing waves.

   • Antinode: The location of maximum amplitude of a standing wave.

   • Normal modes: Possible standing wave patterns on a string.

   • Fundamental frequency: The lowest frequency that will produce a standing wave.

   • Overtones: Higher frequencies which produce standing waves.

TRACE (Task, Request, Action, Context, Example)

TRACE is handy when you want to provide a clear example of the desired output. This strategy is helpful for tasks where modeling is important, such as writing in a certain style or tone.

• Task: Define the specific task

• Request: Describe what you are asking for

• Action: State the action you need

• Context: Provide the context or situation

• Example: Give an example to illustrate your point

ChatGPT, your task (Task) is to help me craft a reply (Action) to this customer complaint email below (Context). I request a professional and empathetic response (Request), similar to the way a customer service representative would respond (Example).

I purchased one of your company's laptop computers through my local computer equipment store on July 10, 2023. Since then, I have experienced serious difficulties with this product. The initial installation and setup was complicated and problematic, and it was challenging to get adequate answers or information from your customer support department. I am still having difficulty with the computer, as a result of its poor quality.

Please contact me at the phone number listed at the top of this letter so that I can provide further details regarding this complaint and so we can resolve this. Thank you for your prompt attention to this matter.

Subject: Re: Your Recent Experience with Our Laptop Computer - Let's Make Things Right

Dear [Customer's Name],

Thank you for bringing your concerns to our attention. We deeply regret to hear about the difficulties you've been experiencing with our laptop and the subsequent challenges you've faced with our customer support. Our aim is to always deliver top-quality products and support, and we are truly sorry if your experience fell short of that.

Please know that your feedback is essential to us, and we appreciate your patience and understanding as we work towards resolving this issue. We have a dedicated team committed to addressing any shortcomings promptly and effectively.

I would like to personally assist you to rectify the situation. As a first step, we want to gain a full understanding of the specific issues you're encountering with the laptop. I'll call you at the earliest possible convenience to discuss the situation and explore suitable solutions.

Additionally, we want to ensure that you feel supported throughout this process. If there are any further questions or concerns you have about the setup or operation of the laptop, I encourage you to reach out directly to me. We're committed to improving your experience and making sure you can use our product to its full potential.

Again, thank you for reaching out and expressing your concerns. Your feedback gives us an opportunity to learn and improve, and we're committed to ensuring your satisfaction. We appreciate your business and look forward to resolving this matter swiftly and to your satisfaction.

Kind regards,

[Your Name] [Your Position] [Your Contact Information]

ERA (Expectation, Role, Action)

ERA is a good strategy for tasks where the outcome is more important than the process. Use this when the final result matters more than how ChatGPT gets there.

• Expectation: Describe the desired result

• Role: Specify the role of ChatGPT

• Action: Specify what actions need to be taken

ChatGPT, I expect a clear and concise summary (Expectation) of this article. As my AI assistant (Role), please read the article and generate the summary (Action).

[In this case, I pasted in the Fitch Ratings downgrade of the US again]

Fitch Ratings has downgraded the United States' Long-Term Foreign-Currency Issuer Default Rating (IDR) from 'AAA' to 'AA+' primarily due to anticipated fiscal deterioration, increasing government debt, and a perceived decline in governance over the past twenty years. Contributing factors include a predicted rise in the general government deficit to 6.3% of GDP in 2023, from 3.7% in 2022, concerns over growing social security and Medicare costs, and a projected increase in the U.S. debt-to-GDP ratio to 118.4% by 2025 from 112.9% in 2023. Despite these concerns, the U.S. economy's structural strengths are acknowledged, particularly its size, diversity, and the role of the U.S. dollar as the primary global reserve currency. However, Fitch predicts a mild recession in late 2023 and early 2024 and a GDP growth of just 0.5% in 2024 due to tighter credit conditions and a consumption slowdown. The U.S. maintains a high ESG Relevance Score, indicating strong institutional capacity, effective rule of law, and a low level of corruption.

ROSES (Role, Objective, Scenario, Expectation, Steps)

ROSES is an ideal strategy for problem-solving tasks where you want ChatGPT to work through a specific scenario and provide a solution. It's especially useful for brainstorming or ideation sessions. Personally, I am a huge fan of this one, and often use a style like this to help me through writers block!

• Role: Specify ChatGPT's role

• Objective: State the goal or aim

• Scenario: Describe the situation

• Expectation: Define the desired outcome

• Steps: Ask for actions needed to reach the solution

ChatGPT, as my brainstorming partner (Role), our objective is to come up with potential topics (Objective) for my upcoming blog post on sustainable agriculture (Scenario). I expect a list of 10 engaging and relevant topic ideas (Expectation), so please research recent trends and suggest topics (Steps).

Absolutely, I'm glad to assist you in brainstorming potential topics for your blog post on sustainable agriculture. Here are 10 topic ideas that are both engaging and relevant:

1. "The Role of Technology in Sustainable Agriculture: Current Trends and Future Possibilities."

2. "Urban Farming: How It Contributes to Sustainable Agriculture and Food Security."

3. "Regenerative Agriculture: A New Approach to Soil Health and Food Production."

4. "Climate-Smart Agriculture: Strategies for Mitigating Climate Change."

5. "Organic Farming Vs. Conventional Farming: A Comparative Analysis on Sustainability."

6. "Vertical Farming: An Innovative Solution for Agricultural Sustainability in Urban Areas."

7. "The Impact of Sustainable Agriculture on Biodiversity Conservation."

8. "The Role of Aquaponics and Hydroponics in Sustainable Agriculture."

9. "The Importance of Crop Rotation and Diversification in Sustainable Farming."

10. "Sustainable Agriculture Policies: An Examination of International Best Practices."

These topics are designed to be broad enough to allow for an in-depth exploration of each subject, but they can also be further narrowed down to fit the specific themes or angles you wish to explore in your blog.

Conclusion

So, there you have it, a toolkit of prompt strategies designed to help you navigate and optimize your interactions with ChatGPT. Just remember, different strategies will excel in different contexts. It's all about experimentation and exploration to see what fits best for your unique use case.

Just like learning a new language, becoming fluent in 'Promptese' requires practice. The more you play around with these strategies and implement them, the more you'll understand the nuances and the better your results will be.

But this is just the tip of the iceberg. We want this conversation to continue evolving, and your insights are a huge part of that. Perhaps you have a go-to strategy we haven't listed here? Or maybe you've stumbled across a novel way to guide ChatGPT that others could benefit from?

So, go ahead and drop a comment below about your experiences, favorite strategies, and any golden nuggets of wisdom you've uncovered in your ChatGPT journey. Remember, every piece of input helps the community grow smarter and stronger together.

Happy prompting!

Leave a comment

Subscribe now

Many users, it seems, haven't realized that with a technique called 'prompt engineering,' you can shape the output to suit your needs better. Picture this: you're looking to write a children's bedtime story in the style of a favorite author. By showing ChatGPT examples of that style, and then asking it to write something similar, you can effectively guide the AI's responses.

In today's post, we're going to delve into some common pitfalls when using ChatGPT for content creation. We'll highlight where users often go wrong and how to avoid these mistakes. Additionally, we'll provide some examples to help you create more targeted, effective content. So, buckle up, and let's explore how to make the most of ChatGPT together!

Understanding AI Limitations

So, let's get real. Have you ever tried asking Siri about her feelings? Or tried explaining to Alexa why that last episode of your favorite show made you cry? If you have, you've probably found they're not quite up to the task. AI, including our pal ChatGPT, simply doesn't have the ability to genuinely understand or be aware of context the way humans do.

They're pros at processing information, sure, but the understanding part, that's a different ball game. You see, when we humans process info, we link it with emotions, past experiences, cultural background, and a whole lot more. This allows us to grasp the subtleties of language and context. For an AI, though, words are more like a puzzle to be pieced together based on patterns rather than experiences to be understood.

And let's face it, life is messy and full of exceptions, right? But AI thrives on consistency, not exceptions. This can lead to some limitations, especially when it comes to understanding sarcasm, irony, or cultural nuances. So, while ChatGPT can be a great tool to help with tasks and even write up a storm, expecting it to truly comprehend complex human nuances might leave you scratching your head.

Let’s jump into a real-world example:

Practical Application: Tailoring Content to Your Desired Style

Okay, now that we've put all those concerns on the table, let's switch gears a bit. Remember how I said that with a little prompt engineering you can get ChatGPT to spit out content more aligned with your style? Let's dive into that.

Let's say you're aiming to write a piece that reads like something out of a high-brow financial publication. You'd start by providing ChatGPT with a couple of example passages that nail the style you're going for.

Here is how I would approach this, after opening a new ChatGPT session, paste the following text in:

Today I am going to ask you to help me write a piece on the current economic climate in a specific style. I am going to feed you some examples of writing styles and then ask you to help me write a piece with some new information. Do you understand? Reply simply with YES

Now remember, ChatGPT is not deterministic. So, while you can expect to get a ‘YES’ from that prompt above…the responses to prompts later may be completely different! I’ll show you some examples of content below, however, I would recommend pasting in some either your own content or that of a style you are targeting (We’ll get into ethics around this later!)

I pasted in 3 other samples, following the same format, however, changing Example 1 to Example 2, Example 3, etc.

Now, let’s say I want a piece covering the current state of the Commercial Real Estate market, just passing in some thoughts in a bulleted format:

Can you write an article for me describing the current state of the Commercial Real Estate market in the style I described above, using the points I mention below:

The commercial real estate industry is struggling because more people are working from home and shopping online due to the pandemic. This change has lowered the demand for office and retail spaces.

Because people are using these spaces less, their value might not increase again for a long time. If property owners can't find tenants, they might lose more money than they did in past economic downturns.

Major banks around the world hold about half of the $6 trillion debt tied to commercial real estate. They are losing more money on these properties and expect the losses to continue.

U.S. banks have revealed they are losing more money on property investments. They also warn that the companies owning industrial and office properties are almost 18% more likely to not be able to pay back their loans.

Banks are cautious about putting money into commercial property refinancing, due over the next two years. This is because customers are moving their money to safer investments that offer better returns, like money market funds and Treasury bonds.

Despite the drop in property values, some global policymakers believe the changes in how we work will not lead to another financial crisis like in 2008-09. They expect that banks will be able to manage their loan losses even if property values drop a lot.

Still, some investors are preparing for lower returns from property. They are expecting about half of what they used to earn before the pandemic, and they may need to accept these lower returns as the new normal.

And voila! ChatGPT will serve you up a draft in the style of your provided content, based on the topics you've listed.

The Great Struggle: Current State of the Commercial Real Estate Market

The commercial real estate industry is in a state of unease as new work-from-home norms and online shopping habits reshape the landscape. The pandemic has shifted people's lives into their homes, dimming the demand for office and retail spaces.

As a result of these shifting dynamics, commercial properties, once the shining star in the portfolios of investors, are facing a challenging outlook. With people spending less time in offices and malls, the value of these properties may stagnate or even diminish for an extended period. Property owners are facing the grim possibility of losing more money than they did in previous downturns if they fail to secure tenants for their vacant spaces.

Adding to the sector's woes, significant players in the financial world are grappling with substantial losses. Major banks around the globe hold approximately half of the $6 trillion debt associated with commercial real estate. As the sector grapples with the new realities, these banks are witnessing their profits erode and anticipate that this downward trend will persist.

In the United States, the strain on the industry is particularly evident. Banks have disclosed increasing losses on property investments. Alarmingly, they also warn that the probability of default by companies owning industrial and office properties has surged by nearly 18%.

Amidst this turmoil, banks are taking a cautious stance when it comes to commercial property refinancing. Over the next two years, considerable amounts of commercial real estate loans are due for refinancing. However, financial institutions are wary of this process. This is driven by a new trend among customers who are redirecting their funds towards safer, higher-yielding investments such as money market funds and Treasury bonds.

Despite the gloomy outlook, some policymakers across the globe maintain an optimistic stance. They argue that the current seismic shift in workplace norms will not result in another financial crisis akin to 2008-09. Their belief hinges on the assumption that banks will navigate the falling property values and manage their loan losses effectively.

However, the future of commercial real estate as an investment is set to undergo a transformation. Investors, traditionally drawn by the attractive returns from this sector, are bracing for a new era of diminished returns. The expectation is that yields will halve from the pre-pandemic average, and investors may need to accept this reality as the new normal.

In conclusion, the commercial real estate market is grappling with unprecedented challenges presented by the pandemic and the associated shift in societal norms. The road to recovery may be long, but the industry must adapt to the changing dynamics to navigate these uncertain times successfully.

Remember, ChatGPT isn't psychic. It won't magically know the style and content you're looking for unless you give it a nudge in the right direction. But with a little nudge (okay, maybe sometimes a big push), you'll be surprised by how close it can get to hitting the bullseye. That's prompt engineering for you - less of a secret sauce, more of a little seasoning to bring out the flavor you want. What do you think about the piece it generated above? Let us know in the comments!

Now onto a couple things you should keep in mind as you take this journey yourself:

Accuracy and Fact-Checking

You've been there. You hear something exciting, a fun fact or a wild news story, and you can't wait to share it. But, oops! It turns out it wasn't true at all. Now imagine this happening on a massive scale. That's what can happen with AI. When ChatGPT provides information, it does so based on patterns it's observed in the data it was trained on. Unfortunately, sometimes those patterns might be based on outdated or incorrect info.

So, while ChatGPT can serve up some pretty intriguing pieces of info, it's essential to remember it doesn't have the ability to verify the accuracy of that information. AI isn't able to critically analyze or fact-check its sources, so it's essential that we humans stay in the loop to validate the information before making decisions based on it.

Remember, no one wants to be the person spreading misinformation, right? Whether it's a casual conversation with friends or a crucial business decision, it's crucial to fact-check any AI-generated info.

Lack of Original Thought and Creativity

AI has undoubtedly revolutionized many areas of our lives. It helps us manage our schedules, recommends what movies to watch, and even generates content. But when it comes to genuine creativity and original thought, well, AI falls a bit short. You see, ChatGPT and other AI can generate content, but they do so based on patterns they've seen before. They're really good at this, but creating something entirely new? That's a different story.

Think of it like this: AI is like a talented cover band. They can perform some amazing renditions of existing songs (or in this case, content), but ask them to create an original song, and they won't know where to start. They can't because their entire function is based on replicating, not innovating.

So, while you can use AI to generate some great content, it's important to remember that true originality, the kind that comes from unique human experiences and imagination, isn't in AI's wheelhouse. They're more like a DJ remixing old hits rather than a musician composing a brand-new song.

Ethical and Privacy Concerns

Hey, remember that time we had a sit-down with Brian Weiss and delved into the ins and outs of navigating compliance and security with ChatGPT in a regulated environment? (If you missed it, check it out here: Navigating Compliance and Security with ChatGPT in a Regulated Environment). Well, that was just the tip of the iceberg. Beyond just the regulated environment, there's a broader spectrum of ethical and privacy concerns when it comes to AI.

AI technologies, like our pal ChatGPT, are a bit like those comic book characters with no moral compass - they don't distinguish right from wrong. They function based on programming, and that can create some headaches, especially when it comes to potentially misleading or harmful content. If an AI system drops the ball and shares incorrect or damaging information, who's in the hot seat? The user? The developer? It's a tricky question that needs some serious thought.

And let's not forget about privacy. With data being the lifeblood of AI, it's like walking a tightrope between helpful personalization and a total invasion of privacy. And when you toss in the potential for AI to be used maliciously, you've got a recipe for some pretty serious ethical dilemmas.

Closing Thoughts

We've covered a lot of ground today, haven't we? We've dug into the drawbacks of using ChatGPT, from its limitations in understanding to accuracy issues, creativity constraints, and ethical concerns. We've also touched on how a little prompt engineering can help you get more out of ChatGPT, molding its responses to better fit your style and needs.

The journey with AI, and ChatGPT in particular, isn't perfect. It's a bit like navigating an uncharted path—you'll stumble upon a few snags, maybe even take a tumble or two. But the cool part? You also get to discover some breathtaking views and hidden gems along the way.

When we open up to AI's potential and the amazing ways it can support us, while also being aware of its shortcomings, we're able to make better, informed choices about how we use it. As we said before, AI isn't here to replace us—it's here to aid us. So, let's make the most of it, shall we?

And this is where you come in. We'd love to see how you're using ChatGPT in the comments section below! What are you creating? What prompts are you using to engineer the responses? What gems have you found, and what pitfalls have you managed to sidestep? Sharing your experiences not only helps us all learn, but it also adds to our collective knowledge and helps shape the future of AI usage. So, let's get the conversation started!

Happy Prompting!

Subscribe now

The answer lies in predictive analysis. This powerful tool uses historical data and advanced algorithms to forecast future events, trends, and patterns, providing invaluable insights to those in the CRE industry. However, traditional methods of predictive analysis have been labor-intensive and prone to error, often failing to capture the intricate, dynamic nature of real estate markets.

Enter artificial intelligence (AI). With the power to process vast amounts of data quickly and accurately, AI has the potential to revolutionize predictive analysis in CRE. Among the various AI tools available, OpenAI's ChatGPT stands out for its advanced language processing capabilities, which allow it to understand and generate human-like text. This makes it an excellent tool for interpreting complex data and providing insightful predictions.

In this blog post, we'll explore how ChatGPT can streamline predictive analysis in commercial real estate, making it more efficient and accessible—even for those without a background in data science or programming. Whether you're a seasoned CRE professional or a novice investor, you'll discover how ChatGPT can become a powerful ally in your decision-making process. Let's dive in.

Understanding Predictive Analysis

Predictive analysis is a data-driven technology that uses information management, statistical algorithms, and machine learning techniques to identify the likelihood of future outcomes based on historical data. It's all about providing a best assessment on what will happen in the future, so organizations can feel more confident that they're making the best possible business decision.

In the realm of commercial real estate (CRE), predictive analysis plays a pivotal role. At its core, it helps stakeholders - whether they are investors, property developers, or real estate brokers - to make informed decisions backed by data. Decisions such as whether to invest in a particular property, when to sell, or how to price a property, can significantly benefit from predictive analysis.

Traditional methods of predictive analysis in CRE have relied heavily on manual data collection and interpretation. These methods often involved collecting data from multiple sources, such as government reports, market surveys, and economic forecasts, followed by the task of sifting through this data to identify relevant trends and patterns. However, this process was time-consuming and prone to human error. Additionally, these traditional methods often failed to capture the complexity and dynamic nature of real estate markets, making predictions less reliable.

Moreover, the vast amount of data involved in real estate market predictions — ranging from property features, local market trends, economic indicators, to demographic shifts — can be overwhelming. Processing this data manually is not only tedious but also opens up a wide margin for error.

Therefore, the demand for more sophisticated, accurate, and efficient methods of predictive analysis in CRE is higher than ever. This is where artificial intelligence comes in, offering potential solutions to these challenges. In the following sections, we will explore how AI, and specifically ChatGPT, can revolutionize predictive analysis in commercial real estate.

The Power of AI in Predictive Analysis

When it comes to predictive analysis, artificial intelligence (AI) presents an enormous leap forward from traditional methods. While conventional analysis techniques rely on manual data gathering and interpretation, often limiting the scope and accuracy of predictions, AI brings an unparalleled capability for processing vast quantities of data, identifying complex patterns, and learning from previous outcomes to refine future predictions.

AI-powered predictive analysis uses advanced algorithms and machine learning techniques to sift through historical data, identify correlations and patterns, and predict future outcomes. It can do this on a scale and at a speed that no human analyst could match. This makes AI a powerful tool for any industry that relies on predicting future trends, including commercial real estate.

There are several AI technologies that are particularly beneficial for predictive analysis in real estate:

1. Machine Learning (ML): ML, a subset of AI, involves training machines to learn from data and improve their performance over time without being explicitly programmed. It's particularly useful in predictive analysis as it can identify patterns and trends in large datasets and use these insights to make predictions about future events or behaviors. For example, ML can analyze past real estate transactions, economic indicators, and market trends to forecast future property values or rental rates.

2. Natural Language Processing (NLP): NLP is an AI technology that enables machines to understand, interpret, and generate human language, including written text. It's crucial for predictive analysis in real estate as it can process and analyze unstructured data, such as news articles, social media posts, or customer reviews, to glean insights about market sentiments or emerging trends. It's NLP that powers ChatGPT's ability to understand and generate human-like text, making it a valuable tool for interpreting complex data and delivering accessible insights.

3. Deep Learning (DL): DL, another subset of AI, involves training artificial neural networks on a large amount of data. These neural networks mimic the human brain's ability to recognize patterns and make decisions based on those patterns. DL can be particularly useful for analyzing visual data, such as images or videos of properties, to extract useful information, such as the condition of a property or trends in property design.

By leveraging these technologies, AI can dramatically improve predictive analysis, making it faster, more accurate, and more comprehensive. And with tools like ChatGPT, you don't need a background in data science or coding to harness the power of AI for your real estate analyses.

How ChatGPT Facilitates Predictive Analysis in Commercial Real Estate

For those who've been following along with Prompts.Finance, you're likely familiar with ChatGPT, a powerful AI developed by OpenAI. For our newcomers, here's a brief introduction. ChatGPT is designed to generate human-like text based on the prompts it receives. It's been trained on a diverse range of internet text, giving it the ability to understand context, recognize patterns, and produce detailed responses. But where ChatGPT really shines is in its versatility. It's not just about generating text; this AI can be an invaluable tool across various sectors, including commercial real estate. Let's delve deeper into how ChatGPT can assist in predictive analysis in this field.

Data Interpretation and Trend Identification: ChatGPT can sift through large volumes of data, including historical property transaction data, market trends, economic indicators, and more, to identify patterns and trends. You can ask ChatGPT to interpret complex data points or reports and generate human-readable summaries or insights, making the data easier to understand and act upon.

For example, if you're looking at a report on past rental rates in a certain city, you could ask ChatGPT,

What does this data suggest about future rental rates in this city?

Based on the information available, ChatGPT can generate an analysis, identifying patterns and predicting potential future trends.

Understanding and Predicting Market Sentiments: Leveraging its Natural Language Processing (NLP) capabilities, ChatGPT can analyze unstructured data such as social media posts, news articles, and customer reviews to understand market sentiments. For instance, you can feed ChatGPT with news articles about the real estate market in a particular region and ask it to predict how the market might evolve based on the prevailing sentiment and trends identified in the news articles.

Here are some ideas for prompts:

I have a collection of news articles and social media posts about the real estate market in Boston over the past year. Can you analyze these and provide an overview of the market sentiment?

Based on recent discussions on real estate forums and social media platforms, what are the expected trends for the commercial property market in Los Angeles?

Can you analyze the sentiment of these customer reviews and predict how it might affect the demand for residential properties in Miami?

Generating Predictive Reports: ChatGPT can be an asset when you need to prepare comprehensive reports based on your predictive analysis. It can help you draft summaries of your findings, create full reports complete with introductions, body, and conclusions, and even generate human-readable explanations of complex data trends. You just need to provide the data and ask the right questions.

Can you generate a summary of my analysis on future property prices in New York based on the given historical data and economic indicators?

Based on our discussion about the real estate market trends in Seattle, can you create a comprehensive report predicting the market's future in the next five years?

I need to draft a predictive analysis report for the commercial real estate market in Chicago. Could you help me outline the key sections and generate initial content for each section?

Real-world Example: Using ChatGPT for Predictive Analysis

Let's take a real-world example. Imagine you are a commercial real estate investor interested in the San Francisco market. You have access to a significant amount of past transaction data and economic indicators but need help identifying trends and making future predictions.

You could use ChatGPT to analyze the data and generate predictions. You could ask,

Based on past transactions and economic data, how do you predict the commercial real estate market in San Francisco will evolve in the next five years?

ChatGPT would analyze the data and generate a detailed prediction based on identified trends.

This example illustrates how ChatGPT can be a powerful tool for predictive analysis in commercial real estate. By providing detailed, human-readable insights based on complex data, it can help investors make more informed decisions and gain a competitive edge in the market.

The Benefits and Challenges of Using AI for Predictive Analysis

AI tools like ChatGPT are revolutionizing predictive analysis in commercial real estate (CRE), offering several key benefits that can enhance decision-making processes.

Accuracy: AI models can analyze massive datasets with far greater precision than manual processes. This increased accuracy can lead to more reliable predictions and forecasts, thereby reducing risks associated with CRE investments.

Efficiency: Traditional predictive analysis methods often require a significant amount of time and resources. AI can automate many of these processes, enabling analysts and investors to gain insights quicker and focus more on strategy and decision-making.

Scalability: AI algorithms can analyze vast amounts of data, far beyond human capability. This scalability enables a comprehensive analysis of multiple markets, property types, and other variables, providing a more holistic view of the CRE landscape.

Personalization: AI, and specifically ChatGPT, can be tailored to individual user needs. For example, you can ask ChatGPT to provide predictive insights on specific markets, property types, or investment strategies.

Despite these advantages, it's crucial to acknowledge some challenges associated with using AI for predictive analysis:

Data Quality: AI models are only as good as the data they are trained on. Inaccurate or biased data can lead to faulty predictions. To mitigate this, it's important to source data from reliable sources and validate it for accuracy before use.

Transparency: AI models, especially those employing complex machine learning algorithms, can sometimes act as a "black box," making it difficult to understand how they arrived at a certain prediction. In such cases, it's crucial to use AI tools alongside traditional analysis methods and consult with experts to interpret AI-generated predictions.

Hallucinations: AI models, including ChatGPT, may sometimes generate "hallucinated" content, meaning they might provide information that is plausible-sounding but incorrect or not present in the data they were trained on. To mitigate this, it's essential to verify key insights from AI models with other data sources and involve human expertise in the interpretation of the AI's outputs.

Overreliance: AI can be a powerful tool, but it should not be the only one in your toolbox. Predictive analysis should also consider factors that may be hard to quantify or capture in data, such as policy changes, upcoming market disruptions, and more.

In summary, while AI tools like ChatGPT offer powerful capabilities for predictive analysis in CRE, they should be used as part of a broader strategy. By understanding both their potential and their limitations, you can leverage AI to drive better investment decisions in the commercial real estate market.

Summary

As we navigate further into the era of AI-driven predictive analysis, your insights and experiences become an invaluable part of the conversation. Have you integrated AI tools like ChatGPT into your capital markets analysis process? What were your observations and learnings? Sharing your experiences can not only contribute to our community's collective knowledge, but it also helps refine and improve these cutting-edge tools.

To stay informed about the latest in AI and finance, consider subscribing to our newsletter. It offers a deep dive into industry trends, groundbreaking research, and the latest news, delivered straight to your inbox.

Subscribe now