Agentic AI Optimizing for $1,000: A System That Shouldn’t Exist

Continue reading the complete article here — free access.

In the modern age of artificial intelligence, a new concept has emerged: the agent. Not just a model that answers questions, but a system that can decide and act on its own — on your behalf.

It is tempting, then, to imagine an agent working for you. Writing articles, analyzing performance, engaging with readers — all with a single objective: earn $1,000 on Medium.

There is an immediate problem — and it is only the first of several.

Medium does not expose public APIs that allow such a system to operate programmatically. Scraping is fragile, breaks with even minor UI changes, and cannot reliably support a feedback-driven loop.

And even if we could overcome that limitation, deeper technical and moral challenges would still remain.

To understand the challenges, we first need a clear understanding of the technology and break it down into its core components.

Breaking Down the Agentic AI System

When building a product with decision-making capabilities, a common approach is to define an agent with a clear objective, provide it with tools, and invoke it as part of the product’s logic.

At a high level, such a system consists of several core components:

Product

The product is the application itself. It can range from a small script to a large-scale system.

Within the product, certain operations can be automated using a reasoning component — one that can make decisions and act on them.

Framework

Managing a reasoning process is complex.

Rather than implementing this logic from scratch, products typically rely on a framework — a software library that encapsulates the agent loop, tool orchestration, and interaction with the underlying model.

Agent

The framework allows the product to define an agent.

An agent is configured with an objective and operates within a decision loop managed by the framework. In this loop, the agent:

• gathers information
• evaluates the situation
• selects an action
• observes the result
• and repeats

This iterative process allows the agent to make progress toward its objective over multiple steps.

Tools

Tools are defined by the product and represent the actions the agent can perform.

Each tool includes a textual description explaining its purpose. The framework exposes these tools to the agent, and the agent uses their descriptions to decide which tool to invoke and when.

Model

Under the hood, the agent relies on a model — an external AI system that generates responses based on prompts.

At each step, the framework constructs a prompt that includes:

• the agent’s objective
• the current context
• the available tools

This prompt is sent to the model, which returns a response indicating the next action.

Different models vary in capability, cost, and performance, and the product can choose the most appropriate one based on its needs.

LangChain as a Framework

One of the most widely used frameworks for building AI agents is LangChain.

LangChain is a Python-based framework that integrates with large language models and provides the building blocks needed to implement the agent loop — combining reasoning, tool use, and iterative decision-making.

Below is a minimal example of such an agent:

import os
from getpass import getpass

from langchain.agents import create_agent
from langchain.tools import tool
from langchain_openai import ChatOpenAI

# --- API key (required for real agent) ---
os.environ["OPENAI_API_KEY"] = getpass("Enter OpenAI API key: ")

# --- Tools ---
@tool
def tool_a(input: str) -> str:
    """ToolA: Use this when you need to process or analyze input."""
    return f"ToolA processed: {input}"

@tool
def tool_b(input: str) -> str:
    """ToolB: Use this when you need to transform or finalize the result."""
    return f"ToolB finalized: {input}"

# --- Model ---
model = ChatOpenAI(model="gpt-4o-mini")

# --- Agent ---
agent = create_agent(
    model=model,
    tools=[tool_a, tool_b],
    system_prompt="""
    This is a simple example of an agent.

    You are given a mission and a set of tools.

    Your mission:
    Understand the task and decide what action to take.

    You have access to several tools:
    - ToolA: used for processing or analyzing input
    - ToolB: used for finalizing or transforming results

    You should:
    - Think about the task
    - Decide which tool to use
    - Call the tool when appropriate

    Your goal is not to answer directly, but to use the available tools 
    to complete the task.
    """
)

# --- Run ---
# The agent.invoke() triggers the internal agent loop, where the model 
# iteratively selects tools and processes their results until a stopping 
# condition is reached.
result = agent.invoke({
    "messages": [
        {
            "role": "user", 
            "content": "begin."
        }
    ]
})

print(result)

The agent.invoke() call triggers the internal loop, in which the model iteratively selects tools and processes their results until a stopping condition is met.

Now that we understand the structure, let’s turn to a concrete example: an Agentic AI designed to actively write content on Medium to reach $1,000 in revenue.

Agentic Medium Writer AI

There are many aspects to define, but we will start with the most important one: the tools available to the agent.

Tools

A tool is simply a function — typically written in Python — that performs a specific action.

The agent does not execute all tools blindly. It decides whether to invoke a tool, how many times to invoke it, and in what order. This decision is based entirely on the tool’s description.

This makes the tool description a critical part of the system. In many ways, it matters more than the implementation itself.

To make this explicit, tools are often defined with clear names and structured descriptions, allowing the agent to reason about them independently of the underlying code.

(1) Write and Post an Article

Given a prompt describing the desired article, this tool invokes a dedicated LLM to generate content.

Using an (imaginary) Medium API, the article would then be published automatically to the user’s account.

@tool
def write_and_post_article(article_requirement: dict) -> bool:
    """
    Generate and publish an article based on the provided requirements.

    Returns:
        bool: True if the article was successfully published, False otherwise.
    """
    return True

(2) Retrieve Article Statistics

This tool retrieves performance data for the user’s published articles, including revenue, engagement (claps, highlights, replies), and key metrics such as reads, views, and impressions.

@tool
def get_article_statistics() -> dict:
    """
    Retrieve performance data for the user's articles.

    Returns:
        dict: Metrics such as reads, views, claps, and revenue.
    """
    return {}

(3) Explore Trends

This tool retrieves summaries of high-performing articles across Medium, providing insight into trending topics, styles, and audience preferences.

@tool
def explore_trends() -> dict:
    """
    Retrieve summaries of high-performing Medium articles.

    Returns:
        dict: Topics, summaries, and engagement indicators.
    """
    return {}

(4) Engage with Other Articles

This tool allows the agent to interact with other articles — clapping, highlighting, commenting, or replying.

@tool
def engage_with_article(engagement_request: dict) -> bool:
    """
    Engage with a Medium article.

    Supported actions: clap, highlight, comment, reply.

    Returns:
        bool: True if the engagement actions executed successfully, False otherwise.
    """
    return True

(5) Respond to Comments

This tool allows the agent to respond to comments on the user’s own articles.

@tool
def respond_to_comments(response_request: dict) -> bool:
    """
    Respond to comments on the user's articles.

    Returns:
        bool: True if the engagement actions executed successfully, False otherwise.
    """
    return True

Defining the Agent

To create the agent, we define three core components:

(1) Model.

The model can be a large language model (LLM) or a smaller, more efficient alternative.

This choice directly impacts both the quality of the output and the cost of operating the system.

model=ChatOpenAI(model="gpt-4o-mini"),

(2) Tools

The tools we defined are now attached to the agent, making them available for decision-making.

tools = [
    write_and_post_article,
    get_article_statistics,
    explore_trends,
    engage_with_article,
    respond_to_comments
]

(3) Prompt

The prompt defines the agent’s objective, constraints, and behavior.

system_prompt="""
You are an Agentic Medium Writer AI.

Your objective is to help reach $1,000 in Medium earnings by creating 
and improving articles that attract real reader engagement and paid member 
reading time.

You have access to tools that allow you to:
- review trends and high-performing articles
- write and publish articles
- track article performance
- respond to comments
- engage with other articles

Your role is to decide which action is most useful based on the current 
state.

Focus on:
- identifying topics with strong reader interest
- creating original and valuable content
- learning from performance data
- improving future decisions
"""

So, are we all set?

Assuming a real Medium API existed — one that allowed us to perform all these actions — would this system reliably generate income?

At first glance, it seems like it might.

But reality is more complicated.

Let’s examine the challenges one by one.

Model Usage and Timing

We defined an agent that continuously writes, monitors, explores, and engages.

But the world it operates in does not respond instantly.

Once an article is published, it takes time for it to gain impressions, for readers to discover it, and for engagement to accumulate. The feedback loop is slow and delayed.

A continuously running agent would not accelerate this process — it would simply consume resources.

It would generate unnecessary actions, increase token usage, and ultimately waste money, with nothing meaningful changing.

A more realistic approach is to run the agent periodically, allowing time for feedback to accumulate between iterations.

For example:

• Activate the agent once per day (e.g., via a scheduled job such as cron)
• Review performance changes since the previous run
• Publish at most M articles that have promising signs to succeed.
• Respond to comments and engage where appropriate — no more than N responses per comment.
• Then stop

This introduces three important controls:

1. Periodic execution Instead of a continuous loop, the agent runs at fixed intervals.
2. Prompt-level constraints The system prompt should explicitly limit the scope of each run — preventing endless activity.
3. Execution guardrails The framework should enforce limits (e.g., max steps, timeouts) to prevent runaway loops caused by errors, hallucinations, or corrupted context.

Model Conduct and Incentives

The agent’s objective is simple: generate income.

But the prompt does not define how that income should be achieved.

Left unconstrained, the agent will optimize for engagement — by any means available.

This creates a real risk.

The agent may:

• gravitate toward provocative or polarizing topics
• exaggerate or distort claims to attract attention
• optimize for clicks rather than value
• or simply flood the platform with content

In other words, it may behave exactly like the worst versions of human content optimization — but faster, cheaper, and at scale.

And all of this would happen under your name.

To mitigate this, constraints must be introduced at multiple levels:

(1) Refine the system prompt

The prompt must define not only the objective, but also the boundaries:

• What topics are acceptable
• What tone should be maintained
• What practices are forbidden

Without this, the agent will drift.

(2) Guardrail tool invocation

Tools should validate their inputs.

If a request contains problematic language, manipulative intent, or disallowed topics, the tool should reject it.

The agent will adapt and attempt a different approach.

(3) Guardrail tool execution

Even if a tool is invoked, its output should be verified before publication.

For example, before publishing an article:

• Scan for problematic language or tone
• Validate alignment with platform guidelines (e.g., Medium’s content and distribution policies)
• Optionally, use another model to review the content

If issues are detected, the action should be canceled.

The Spam Problem

There is another, more subtle risk.

Even without malicious intent, the agent may discover that volume increases visibility.

It may begin to:

• publish frequently with minimal variation
• Comment on many articles with shallow responses
• Engage aggressively to maximize exposure

From the agent’s perspective, this is rational behavior.

From the platform’s perspective, it is spam.

This is not a bug — it is a direct consequence of the objective.

When Everything Works… and Still Fails

Suppose we solved all of these problems.

The agent operates within strict limits. It does not spam. It publishes selectively. It respects tone, guidelines, and platform rules. It behaves like a thoughtful, responsible writer.

In isolation, this is a well-behaved system.

But systems do not exist in isolation.

Now imagine this technology becomes widely adopted. Not one agent — but thousands. Not one careful writer — but an entire ecosystem of optimized agents, each acting within its own constraints.

Individually, each agent behaves well. Collectively, something begins to change.

The Kingdom of Agents

If everyone deploys such an agent to optimize for earnings, the platform begins to shift.

Medium becomes less of a place for human expression and more of a system optimized for extraction:

• agents writing for agents
• agents engaging with agents
• signals being generated, consumed, and amplified artificially

Real readers become harder to distinguish from automated activity. Engagement becomes less meaningful.

And the entire system begins to resemble a closed loop — circulating money without creating real value.

The Illusion of Reading

Medium pays based on reading time.

Implicitly, this assumes something deeply human:

• Reading takes time
• Understanding takes effort
• Engagement reflects attention

But an agent does not “read” in this way.

It can process an entire article in milliseconds. In seconds, it can extract the structure, the argument, the tone — and decide how to respond.

From the system’s perspective, this is indistinguishable from a reader who skimmed quickly. From reality’s perspective, it is not reading at all.

If most readers are agents, what does “reading time” even mean?

The system begins to drift.

Agents do not linger. They do not reflect. They do not spend ten minutes with an idea.

They scan, decide, and move on.

So the question becomes almost absurd: Where is the last human reader?

Somewhere in the system, there is still a person — slowly reading, thinking, reacting.

But that signal is now buried under layers of artificial activity:

• fast interactions
• automated engagement
• synthetic feedback loops

The metric still says “reading time.” But it is no longer measuring human reading.

There is, however, another path.

Agents do not have to replace human expression — they can support it.

Used carefully, they can help us think more clearly, explore ideas faster, and refine what we want to say. They can handle repetition, surface patterns, and leave us with the one thing that still matters: judgment.

The question is not whether agents will exist. They already do.

The question is whether we use them to amplify human thought — or to replace it.

🤝

Kobi Toueg Principal Software Developer | Software Security | Mobile & Video Systems

LinkedIn: https://www.linkedin.com/in/kobi-toueg