The Smarter the Agent, the Less I Want It in Charge
The first version of this project was agent-centric. A general-purpose agent received an objective, gathered information, selected tools, delegated work and eventually approached execution. Security was therefore framed as a problem of constraining the agent: reduce tool access, isolate credentials, filter inputs, validate outputs and limit what downstream components would accept.
That architecture became increasingly awkward. The more seriously I treated financial risk, the more capability I removed from the agent runtime. Broker credentials moved elsewhere. Generic network access became undesirable near execution. Multi-agent delegation remained useful for research but became harder to justify as authority moved closer to capital.
The underlying problem was not simply that the agent was too powerful. It was that the agent owned the investment lifecycle.
A general-purpose agent is designed to solve tasks. An investment system must maintain persistent financial state, react to external events, schedule work, update theses and valuations, manage portfolio constraints and decide when new work is required even when no user or agent initiates a session.
That distinction changes the architecture.
Tickoni is not intended to be a safer general-purpose agent. It is a persistent investment runtime that can invoke general-purpose agents when open-ended reasoning is useful.
1. General-Purpose Agents Solve Tasks; Investment Systems Own State
General-purpose agents are valuable because they can operate under incomplete specification. They can browse, interpret documents, compare evidence, call tools, recover from failures and construct intermediate steps that were not explicitly programmed.
That flexibility is appropriate for tasks such as:
reading an earnings release;
comparing management guidance with previous quarters;
extracting risks from a transcript;
researching competitors;
evaluating qualitative changes in an investment thesis.
The problem begins when that task-oriented runtime becomes responsible for the full investment process.
Consider a company reporting earnings. A research agent can analyze the release, but something else must already know:
whether the company is currently held;
the current position size;
the maximum permitted exposure;
relevant sector and factor exposure;
which thesis is associated with the position;
which assumptions in that thesis matter;
when the previous valuation was produced;
whether a valuation refresh is required;
whether there are pending orders;
how much cash must remain reserved;
whether the position is already scheduled for review.
Those are not research outputs. They are persistent investment state.
The key distinction is therefore:
Hermes can solve arbitrary tasks. Tickoni has to know when those tasks exist, what state they depend on and what they are allowed to change.
2. The Control Flow Has to Be Inverted
A conventional agent architecture starts from the model and expands outward:
model
→ context
→ tools
→ actions
Over time, the agent acquires more capabilities:
agent
├── memory
├── browser
├── MCP
├── plugins
├── sub-agents
├── market data
└── broker
Finance then becomes one capability within a generic agent runtime.
Tickoni reverses that topology:
┌── Hermes
│ open-ended research
│
├── models
│ extraction / reasoning
│
company events ─────┐ ├── filings / transcripts
earnings reports ───┤ │
market events ──────┼─→ Tickoni ─────────→ broker
portfolio events ───┤ │
scheduled reviews ──┤ ├── valuation engines
price movements ────┘ │
├── market data
│
└── analytics
Tickoni owns the event loop and persistent state. External capabilities are invoked as needed.
An earnings event may produce the following workflow:
earnings release
↓
identify affected security and thesis
↓
parse structured results
↓
request qualitative research
↓
retrieve transcript
↓
update assumptions
↓
rerun valuation
↓
recompute expected return
↓
re-evaluate portfolio allocation
↓
apply mandate and risk constraints
↓
hold / resize / exit / investigate further
Hermes can perform the open-ended research step. A deterministic parser may handle reported financials. A valuation engine may calculate a DCF. Another module may compute portfolio risk.
No single general-purpose agent needs to own the workflow connecting them.
The system that owns that workflow is the investment system.
3. The Broker Already Solves a Different Security Problem
One reason the architecture initially became confused is that I was assigning Tickoni responsibilities the broker may already handle better.
A broker is already a deterministic execution boundary.
It can enforce:
available cash and buying power;
account permissions;
margin restrictions;
supported instruments;
order validity;
allowed venues;
settlement rules;
withdrawal restrictions.
If an account has $50,000 of buying power, a properly configured broker does not need an LLM safety classifier to reject a $200,000 cash equity purchase.
This means a direct architecture such as:
Hermes → Broker MCP
is not automatically unsafe.
The broker may reliably prevent many invalid or unauthorized account-level actions.
The problem is that a broker can reject an impossible trade while accepting a strategically unacceptable one.
Consider:
portfolio NAV: $100,000
available cash: $60,000
proposed purchase: $50,000 XYZ
The broker may correctly accept the order.
The portfolio mandate may contain:
max single position: 7%
max sector exposure: 25%
protected cash: 20%
max daily turnover: 10%
The broker does not necessarily know or care about those constraints.
The broker answers:
Can this account execute this order?
The investment system must answer:
What portfolio state is permitted after this decision?
Those are different control domains.
4. Tickoni Cannot Merely Be a Validation MCP
A natural alternative is to keep Hermes as the host and expose Tickoni as a validator:
Hermes
├──→ Tickoni MCP: validate order
└──→ Broker MCP: execute order
For example:
proposal:
BUY 500 XYZ
Tickoni might return:
status: denied
projected_weight: 18.4%
max_weight: 7.0%
max_quantity: 163
This is substantially better than expressing the same rule in a prompt.
It is still insufficient as an authority boundary.
The validation result is only information returned to Hermes. Hermes must still interpret and enforce it correctly.
Possible failures include:
executing 613 shares instead of 163;
validating one order and submitting another;
ignoring a denial;
duplicating an approved order;
executing after portfolio state has changed;
executing after another pending order fills;
using stale validation after the price moves;
bypassing validation and calling the broker directly.
This is also a time-of-check/time-of-use problem.
At t0:
portfolio_state_8142 + order_X → valid
At t1:
broker.execute(order_X)
Between those points, both the portfolio state and the requested action may have changed.
A theoretically clean solution would be a single-use authorization token:
authorization:
portfolio_state: 8142
account: A
symbol: XYZ
side: BUY
max_quantity: 163
max_notional: 10,000
expires_at: 10:31:05
The broker would then execute only orders covered by a valid authorization.
Most brokers do not implement a Tickoni-specific authorization protocol.
More importantly, even this would solve only execution authorization. It would not make Tickoni the owner of the investment lifecycle.
5. Hermes → Tickoni → Broker Is Still the Wrong Abstraction
Another obvious design is:
Hermes
↓
Tickoni
↓
Broker
Hermes performs the reasoning, Tickoni validates and constructs the allowed order, and the broker executes it.
This can be made technically sound, but it still leaves Hermes as the primary application.
Hermes receives the objective.
Hermes decides when research is necessary.
Hermes decides when enough evidence has been gathered.
Hermes decides when valuation should run.
Hermes decides when it is time to call Tickoni.
Tickoni becomes a sophisticated financial tool beneath a general-purpose agent.
If that were the intended architecture, there would be little reason not to implement Tickoni as a plugin or MCP service.
The reason to build Tickoni as a separate system appears only when ownership is reversed.
6. Tickoni Itself Needs an Extensible Financial Runtime
Finance is not one capability, and Tickoni should not bind itself to one agent ecosystem.
A complete investment system needs multiple interchangeable components:
Tickoni
│
├── research / general agents
│ ├── Hermes
│ ├── OpenClaw
│ ├── Pi Agent
│ ├── Claude
│ ├── Codex
│ └── user-selected agents
│
├── research data
│ ├── filings
│ ├── transcript providers
│ ├── earnings parsers
│ └── news
│
├── valuation
│ ├── DCF
│ ├── comparable companies
│ ├── sector-specific models
│ └── scenario analysis
│
├── analytics
│ ├── technical analysis
│ ├── factor models
│ ├── risk models
│ └── market data
│
├── portfolio
│ ├── allocation
│ ├── concentration limits
│ ├── cash management
│ └── optimization
│
└── execution
├── broker adapters
└── paper execution
These components are not independent tools orbiting a single agent. They participate in shared financial workflows over persistent portfolio state.
An earnings parser can update reported financials. That may invalidate assumptions in a valuation. A general-purpose agent may investigate qualitative changes in management guidance or competition. A new valuation changes expected return. Expected return changes relative attractiveness. Portfolio allocation then interacts with cash, exposure, pending orders and risk limits before broker execution becomes relevant.
Tickoni therefore needs its own orchestration model, extension mechanism and state machine.
General-purpose agents should be one plugin category inside that runtime, not the runtime itself.
That distinction also avoids locking the investment system into one agent framework. Hermes may be the best choice for one workflow. OpenClaw may be preferable for another. Pi Agent may suit a lighter local setup. Claude or Codex may be useful where strong coding, document analysis or tool use is required. A user may prefer a completely different agent six months later.
Tickoni should not care, provided the integration satisfies the required interface, identity, resource and audit contracts.
The financial lifecycle should survive that substitution.
It could technically be packaged inside a Hermes or OpenClaw plugin, but then that plugin would still need to own:
persistent portfolio state;
company and thesis state;
event ingestion;
periodic scheduling;
valuation lifecycle;
portfolio lifecycle;
plugin discovery;
agent-provider abstraction;
risk state;
order state;
broker adapters;
audit and replay.
At that point the plugin contains a complete investment runtime, while the surrounding agent framework contributes only one possible implementation of general-purpose intelligence.
That is the wrong dependency boundary.
Tickoni should define the financial system and allow the user to choose the intelligence providers that operate inside it.
The architecture should remain open to whichever agent, model or tool ecosystem proves useful next, without requiring the portfolio engine to migrate with it.
7. Hermes Should Be a Capability of Tickoni
Hermes is useful precisely because it is general-purpose.
Tickoni should not reproduce that functionality.
It should not attempt to build the best browser agent, coding agent, document agent or general research agent.
Instead, Hermes should be callable by Tickoni when a task requires open-ended reasoning.
For example:
Tickoni detects earnings release
↓
load existing thesis and portfolio context
↓
parse structured financial data
↓
invoke Hermes:
"Investigate changes in pricing,
guidance, competition and thesis risks"
↓
receive evidence
↓
update thesis inputs
↓
rerun valuation
↓
recompute portfolio implications
The output of Hermes is evidence.
It does not own the financial state transition.
This makes Hermes replaceable.
A future agent may provide better research.
A deterministic system may outperform it for structured extraction.
A specialist research model may be preferable for a specific domain.
A human analyst may occasionally be the correct implementation.
Tickoni should be able to invoke any of them without changing the portfolio lifecycle.
This leads to a clearer division:
Hermes:
solve an open-ended task
Tickoni:
determine which financial task exists,
provide its state and constraints,
consume the result,
and update the investment process
Broker:
execute valid market instructions
8. The Critical Distinction Is Ownership of Time
The strongest reason Tickoni cannot simply be an on-demand financial plugin is scheduling and event ownership.
A plugin generally waits for its host to invoke it.
An investment system cannot depend on that model.
Tickoni must react to:
earnings calendars;
new filings;
management guidance;
dividend and corporate actions;
price and volatility events;
valuation expiry;
thesis review deadlines;
portfolio drift;
risk-limit proximity;
cash changes;
partial fills;
order rejection;
market-session transitions.
The system therefore needs its own persistent event loop:
event
↓
resolve affected securities / portfolios / theses
↓
load current financial state
↓
determine required workflow
↓
invoke specialist capabilities
↓
update evidence / valuation / thesis
↓
recompute portfolio implications
↓
act, reject, defer or schedule follow-up
This property provides a useful architectural test.
Remove Hermes.
Tickoni should still know:
what the portfolio owns;
why each position exists;
which constraints apply;
when each thesis requires review;
which valuations are stale;
which events remain unresolved;
which orders are pending;
what actions occurred previously;
what needs to happen next.
The system loses a general-purpose research capability, but the investment operation remains intact.
Remove Tickoni.
Hermes can still browse, research, analyze and call tools.
There is no longer an authoritative investment operation.
That asymmetry determines the dependency direction.
9. Security Becomes a Consequence of the Architecture
This project originally moved in this direction because of security concerns, but security is now better understood as a property of the architecture rather than its main purpose.
If Hermes is a replaceable capability, its output can be treated as untrusted evidence.
If a transcript parser is compromised, its result does not automatically become an order.
If an MCP service returns malicious output, that output still enters the financial state machine through explicit validation.
If a model proposes a 70% position, the portfolio engine can reject or resize it.
If multiple agents agree on a trade, consensus does not become authorization.
The core transition becomes:
portfolio(t)
+
new evidence
+
investment mandate
+
portfolio constraints
↓
permitted state transition
↓
portfolio(t+1)
The critical invariant is not that every upstream component behaves correctly.
It is that upstream components cannot arbitrarily redefine the permitted portfolio state.
10. The Portfolio Is the System
I initially described the project as an AI investor.
That framing naturally made the agent the primary object.
The agent researched, reasoned, selected tools and eventually traded.
Everything else became infrastructure attached to the agent.
The architecture now points in the opposite direction.
The durable object is the portfolio and its investment state.
That state survives model changes.
It survives agent-framework changes.
It survives broker changes.
It survives individual research sessions.
It persists across earnings cycles, thesis revisions, valuation updates and thousands of individual decisions.
The agent does not.
Tickoni therefore should not be a financial plugin for a general-purpose agent.
It should be a finance-native runtime that owns persistent portfolio state, event processing, scheduling, valuation lifecycle, allocation, financial constraints and execution orchestration, while using general-purpose agents as interchangeable capabilities.
The design principle is simple:
The agent should be a plugin inside the investment system, not the investment system a plugin inside the agent.
Comments
Post a Comment