Dejar conducir al robot: qué significa automático aquí

The word automatic can sound like an invitation to stop paying attention. In TraderLobby, it means something more specific. A strategy can watch information, check its rules, and request actions without you pressing Buy or Sell for every individual decision. You choose what is allowed to run. You still need to understand the account, the limits, and the results. The robot can handle repeated steps. It cannot take responsibility for your choices.

Think of this as assigning a defined job. You are not asking the app to do whatever it thinks will make money. You are allowing a particular strategy to work within its available settings and permissions. Different strategies can have different purposes. A description of that purpose helps you understand the job, but it does not promise that the job will produce a profit. Automatic describes how an action starts, not how well it will end.

Separate four questions before you look at any results. Do I have access to this strategy? Is it enabled? Which account and mode does it belong to? What funds or limits can it use? Access might come from a subscription or another available entitlement. Access alone does not mean the strategy is running. An enabled strategy also does not mean that every possible order has permission to proceed.

Paper and Live answer a different question. Paper is the practice context. Live can involve actual exchange orders and real funds. Manual and automated describe how an individual action is chosen. These are separate ideas. A manual trade does not turn off all your strategies, and an automated strategy does not turn a Paper account into a Live account. Read the actual labels instead of treating one word as the answer to everything.

There is another important distinction in this app: changing the workspace you are viewing is not the same as stopping background activity. Enabled Live strategies and their position watchers can continue while you look at Paper. TraderLobby can show a notice explaining this. If your intention is to stop something, use the appropriate controls in the correct context and verify their state. Simply leaving a screen does not establish that the work has stopped.

Open Strategies and identify the strategy and context you are reviewing. Then locate the relevant trading status and allocation information available to your account. Some controls depend on your role and permissions. A demonstration account may show controls that you do not have. Read Running, Paused, or any warning as a statement about that control's scope, not as proof that every strategy and every connection is healthy.

For this lesson, keep your practice context unchanged. You do not need to enable anything. Explain one example aloud: I have access to this strategy, but I still need to verify whether it is enabled, where it would run, and what it may use. If those answers are unclear, you have found the next thing to investigate. You have not found a reason to click faster.

A strategy cannot observe the market directly the way you can look out a window. It receives reports. Those reports can include prices, trading activity, and information about an account or position. The app then works with the information available to it. That makes the source and age of the information part of understanding automation. A clear number on a screen is useful only when you know what it describes.

Start with the market and its full pair. Bitcoin priced in U.S. dollars is not interchangeable with every other market that includes Bitcoin. The venue matters too. A public reference price, a chart, and the price available for a particular order can differ. If two numbers are different, first check the pair, source, and time. Do not assume that one number must be wrong or that the strategy will receive the price you prefer.

The Paper workspace identifies its reference context. In the current demonstration, its label describes a delayed Coinbase reference. Read the delay shown in your own app rather than memorizing it as a permanent setting. Practice activity based on that context should not be compared with a current Live quote as if both described the same instant. This connects to the earlier lesson about where market information comes from: the label belongs with the number.

A strategy also needs account information. It may need to know what funds are available, what is already committed, and which positions belong to the relevant strategy and connection. Remember the cash lesson: the headline balance is not always the amount available for another action. Locked funds, existing commitments, reserves, and allocation limits can change what the app can request even when a market condition looks suitable.

Freshness means how recently information was updated. Where the app provides an update time, status, or warning, inspect it. A connection problem or delayed response can leave you looking at an earlier value. Information that has stopped changing is not automatically a calm market. It may be old information. A successful page load also does not prove that every data source behind every panel has just refreshed.

Consider a simple example. You see a price on a chart and expect the strategy to act immediately. The account information may be different from what you remember, the strategy may be waiting for its own conditions, or a required check may not be satisfied. The chart alone cannot tell you which explanation applies. Use the available candidate, strategy, account, and status information to narrow the question instead of guessing from one visual cue.

Before moving on, identify one market label, one account label, and one freshness clue in the app. If a clue is unavailable, say that you cannot confirm it from this view. That is a useful observation. The goal is not to invent confidence from missing information. It is to understand what the strategy could be observing, what you can verify, and what still needs investigation.

A strategy may identify something it wants to do and still be unable to do it. Permission is one reason. For Live activity, TraderLobby uses an authorized exchange connection to request supported actions. That connection is a controlled route to your exchange account. It is not a transfer of ownership of your funds, and it is not an unlimited instruction to act however the app chooses.

Return to API Connections and inspect the selected connection without editing it. Confirm the exchange, the account context shown, and the available connection or order-permission status. Being able to read a balance does not by itself establish that an order can be submitted. A connection can answer one kind of request while another kind is unavailable or rejected. Read the relevant status rather than treating Connected as an answer to every permission question.

Permissions exist at more than one level. Your app role affects which controls you can use. Your access to a strategy affects whether that offering is available to you. The exchange connection affects which account actions are permitted. The current trading context and its controls can also restrict activity. These checks work together. Passing one does not skip the others, and purchasing access does not repair a connection problem.

The account and connection deserve special attention when you have more than one. Two connections can belong to the same exchange and still refer to different account contexts. A strategy result from one context is not proof that another connection is ready. Before interpreting a blocked action, confirm that you are inspecting the connection associated with the strategy or position in question. Matching the coin symbol alone is not enough.

Permission also does not guarantee acceptance. The exchange may apply order-size rules, available-balance checks, market availability, or other restrictions. A request that was allowed to leave the app can still fail to complete as intended. Keep the steps separate in your mind: allowed to request, request received, and action completed. The result must be inspected after the request, not assumed from the permission screen beforehand.

For example, imagine that a strategy is enabled and its subscription is active, but the selected connection cannot place orders. Increasing its allocation would not answer that problem. The useful next step is to read the connection's status and the specific message associated with the failure. Likewise, if a control is unavailable because of your role, changing a strategy setting is not a substitute for the right access.

Your checkpoint is a short explanation: This strategy has access, it belongs to this context, and these are the permissions I can currently verify. Leave credentials private while doing that. You can describe a status without showing an API key or secret. In this lesson we are learning how to inspect the boundaries. We are not changing permissions or moving into Live to test whether an order will go through.

Now put the pieces together. At a high level, an automated strategy watches information, evaluates its conditions, checks whether an action is allowed, and may submit a request. After that, the response and any resulting position or transaction need to be inspected. This sequence is the useful public explanation. You do not need a creator's private formulas or exact thresholds to understand the difference between a possible action and a completed one.

Watching is the information stage. Evaluating is the decision stage. The strategy considers the information according to its defined behavior. It may decide to wait. It may identify something worth acting on. The conditions can change before anything is completed. This is why seeing a promising market, or seeing an item in a candidate view, does not mean that the account has already bought it.

Next come the relevant checks. These can involve strategy availability, enabled state, the account and mode, funds or allocation, connection capability, and the current trading controls. Think of them as questions that must be answered, not as a countdown toward an inevitable purchase. A strategy can have a reason to act while the account does not currently have the capacity or permission for that action.

A request is the instruction sent for processing. In Paper, the activity is handled in the practice context. In Live, the authorized exchange route is involved. Keep those contexts separate when reading results. The important point in either case is that requesting and completing are different events. A loading indicator, a changed button, or a brief notification does not replace checking what was actually recorded.

A fill is an executed amount of an order. The amount, price, fees, and timing may differ from what you expected while looking at a quote. Some outcomes may be incomplete or unsuccessful. Look at the fields and status that the app actually provides. Do not describe a submission as a completed purchase until the available result supports that description. When information is incomplete, keep that uncertainty in your explanation.

Here is a fictional example. A strategy identifies a market, but no position appears immediately. You inspect the correct account and mode, then look for the relevant result in Transactions and Portfolio. If the result is still uncertain, investigate before placing another order by hand. Repeating an action simply because you have not seen its outcome can create a second exposure rather than clarify the first one.

Once you find a recorded result, connect it to the strategy, account, market, and time involved. A similar-looking transaction from yesterday is not confirmation of today's request. A position owned by another strategy is not confirmation either. Those identifying details let you follow the actual sequence instead of constructing a story from unrelated numbers on different screens.

For your checkpoint, describe the sequence in five plain steps: observe, evaluate, check, request, and verify. Then identify where waiting could occur. It can happen before a request, and uncertainty can remain after a request. Understanding that sequence makes automation easier to supervise because you can ask which step you are looking at instead of asking only why the robot has not bought something yet.

An entry is the beginning of a position's story, not the end of your responsibility. Once a holding exists, its value can change, its exit conditions may be monitored, and requests can succeed or fail. Automation can help carry out defined work around that position. It does not promise that the position will close at an exact price, at a convenient moment, or with a profit.

Open Portfolio and read the identity of a position before judging it. The coin is only part of that identity. Inspect its owner or strategy, account or connection, mode, and any position identifier shown in the detail or action dialog. Two holdings in the same coin can have different owners and histories. A result for one should not silently become your explanation for the other.

Position ownership matters when you consider intervention. A holding associated with a strategy is not automatically the same as an app-owned or manual holding. The app uses these distinctions in its views and actions. Read the current labels and any confirmation before changing a position. Do not assume that one Sell action will affect every holding with that symbol, or that changing ownership preserves the same monitoring behavior.

The exit-alert view can help you inspect what is being monitored. Read the position, the nearest condition reported, and the information available about distance or timing. An alert is information about a condition. It is not a receipt for a completed sale. After an expected exit, use the position and transaction records to check whether an action occurred and what amount was actually executed.

A displayed gain also needs context. Unrealized profit and loss describes a holding that is still open, using the valuation available in that view. It can change before a sale. A recorded sale has its own execution price and fees. Do not treat an open green number as cash already secured, and do not expect a later net result to equal an earlier screen estimate exactly.

Stopping deserves the same careful reading. Disabling a strategy, pausing trading, closing a position, removing access, and canceling a subscription are different actions. Do not assume that a pause closes holdings or that every form of stopping leaves exit monitoring active. Some trading controls can block automated exits as well as entries. Their scope and the current position state must be checked before you rely on them.

This becomes especially important during an interruption. If you intend to stop activity, identify the relevant account and mode, read the control's effect, and inspect the returned state. Then check open positions and outstanding results separately. If an order had already been sent, a later pause is not evidence that the exchange canceled it. Confirm the outcome through the available order and account records.

For your checkpoint, choose one example position and explain who owns it, where it belongs, and how you would verify an exit. Finish with this distinction: I can see an exit condition, but I still need evidence of execution. That habit prevents a common misunderstanding. Monitoring a position and finishing a position are related jobs, but they are not the same event.

A quiet strategy is not automatically a broken strategy. It may be waiting for a condition that has not occurred. It may be enabled but unable to act because a limit or permission is not satisfied. It may also be affected by missing information or a connection problem. These situations can all look like no new trade. Your job is to separate them using evidence rather than the length of time you have been waiting.

Start with identity and context again. Are you viewing the intended strategy in the intended mode and account? Then check whether it is enabled and whether the relevant trading state allows activity. A strategy you can browse in the marketplace is not necessarily one you have activated. A status from the Paper context should not be used to diagnose a different Live context without checking that context directly.

Next, inspect the information the app provides about conditions and candidates. A candidate view can help explain what is being considered, but it is not a promise that an entry is next. No suitable candidate can be a valid result. A market can also move away from a condition. You do not need to discover a private strategy formula to recognize that the visible evidence does not establish an imminent trade.

Then check capacity and access. Is the allocation appropriate for the action being considered? Are funds already committed? Does the strategy still have the access it requires? Is the relevant connection able to submit supported orders? Read any specific message before changing settings. A blocked action provides a narrower question to investigate. Randomly changing several controls makes it harder to know what caused the original problem.

Missing information requires a different response from normal waiting. A failed load, unavailable quote, or connection error means you may not have enough current evidence to judge what is happening. Recheck the status and the latest available results. Do not treat an old position table as proof that no recent action occurred. When the app and exchange information appear inconsistent, reconcile the relevant account and time before assuming either view tells the whole story.

A pause or protective interruption also deserves attention. Read the reason if one is shown. Do not press resume or reset merely to remove an uncomfortable status label. First understand what was stopped, which context is affected, and whether existing positions or submitted requests need attention. Removing a restriction does not explain its cause or establish that the underlying problem has been resolved.

Imagine that an enabled strategy has made no new trade today. If its context is correct, data is available, and no blocking message appears, it may simply be waiting. If the connection reports an error, that is a different starting point. If the displayed state cannot be confirmed, say so. Three different explanations call for three different investigations; none is solved by assuming that more activity must be better.

Your checkpoint is to sort an example into waiting, blocked, or uncertain. Say what evidence supports your choice and what you would inspect next. If you need help, record the time, mode, strategy, and exact message without including credentials. A specific report gives someone a place to start. The robot did nothing is an observation; the surrounding facts turn it into a useful question.

You now have a way to supervise automation without watching every price movement. Build a routine that checks context, permission, capacity, activity, and results. The purpose is not to predict the next candle. It is to know what you have authorized, what is actually happening, and what needs your attention. A repeatable check is more useful than opening the app only when a number surprises you.

Begin with context. Confirm the account, connection where relevant, and Paper or Live mode. Remember any enabled activity in a different workspace. Viewing Paper does not prove that Live strategies have stopped. If you manage more than one context, make your notes specific enough to distinguish them. I checked my account is less useful than naming which context you checked and when.

Next, review the strategies you have enabled and the resources available to them. Confirm the identities and versions shown, the access status, and the allocation or budget information relevant to your setup. Look at tradable funds and existing commitments, not just a large balance at the top of the page. Changes to access or settings deserve a fresh review of what they mean for the work already underway.

Then inspect activity and open positions. Read the available status and update information, review any exit alerts, and investigate warnings that affect your context. Connect positions to their owners and accounts. A total portfolio number can summarize value, but it does not explain every holding. When a result is unexpected, narrow the question to the specific strategy, position, market, and time involved.

Check the evidence of completed actions in Transactions and the relevant position records. Compare the amount, execution information, fees, and status provided. A request, an alert, and a completed trade can appear in different places for different reasons. Keep them separate in your explanation. If an outcome is unresolved, mark it as unresolved rather than filling the gap with what you hoped would happen.

Now rehearse a calm response to a surprise. Suppose a position remains open after you expected an exit. First identify the exact holding and context. Read the alert or condition information, look for a submitted or recorded action, and check for an interruption. If you choose to intervene later, review the relevant control and verify its result. Do not repeat an uncertain sell or change several unrelated settings just to make the screen look different.

Keep a short record of what you found: the time, context, strategy or position, message shown, and any verified change. You can do that in your own notes. There is no need to expose an API key, secret, or private account information. If support is needed, these facts help explain the issue. They also help you distinguish a new problem from a result you already investigated.

Before finishing, answer four questions. What have I allowed to run? Where can it act? What evidence shows what it has done? What would I check before stopping or resuming it? If you can answer those clearly, you understand the central meaning of automatic in TraderLobby. The app can carry out repeated work. You remain the person who understands its boundaries and checks its results. In the next chapter, we will look more closely at turning strategies on and off.